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With Bravado; your decision to get into 
multimedia is really quite simple. 



If you’re thinking about developing multimedia applications, Truevision Bravado 
Multimedia Engines make a green light even greener. 


Why are the developers crossing the street? 


■ Controllable video-in-a-window 

■ Stereo or monaural audio 


■ Microsoft® Windows'" 3.x drivers, with 
Multimedia Extensions 

■ MS-DOS® drivers 


■ 8- or 16-bit VGA on-board 

■ Comprehensive Developer Toolkit 

■ Powerful expansion capabilities 

■ Outstanding technical support 
Multimedia is where developers and integrators are headed, and the pace is 

quickening. Truevision Bravado gets you up to speed with extensive functions and full 
support. Traffic is starting to get heavy, so get going with Bravado. 

For more information on the Truevisionary Developer Program, 

CALL 1 -800-344-TRUE and ask for Operator 5. 


When it comes to video, it comes from Truevision™ 


d Truevision 

7340 Shadeland Station, Indianapolis, IN 46256 

INTERNATIONAL: Brazil 55-192-329-956 Canada 416/940-8727 France 33-1-3-952-6253 Spain 34-1-563-0282 
Italy 39-2-242-4551 U.K. 44-628-77-7800 Germany 49-89-612-0010 Other International 617/ 229-6900 
© 1992, Truevision, Inc. 
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C CODE FOR THE PC 

source code, of course 

Embedded DOS (full-features, real-time, multitasking, 3.31-compatible DOS for embedded system and self-bootable installations).$375 

Style (a C+ + class library to build, maintain and traverse arbitrary, non-taxonomic links between C++ objects).$300 

Spell Time (spelling checker for incorporation into text products; no royalty; large dictionary; small and fast) .$300 

ZIP Image Processor & Victor Image Library Version 2.2 (brightness, contrast, merge images, TIFF/GIF/PCX/bin, HP ScanJet support) . . $290 

NE W! INGRAF (graphics for scientists & engineers, all sorts of graphs & plots; specify Microsoft or Borland).$275 

NE W! The Snooper (Ethernet protocol analyzer for Novell NetWare and LAN Manager Networks; capture packets; real-time display).$275 

Report Ease (report writer and mail merge engine, include forms and produce reports from your product; no royalties).$275 

TUrboTnX (Release 3.0; HP, PS, dot drivers; CM fonts; LaTjjX; MetaFont).$250 

Rogue Wfcve tools.h+-(- or math.h++ Class Library (extensive docs).each $240 

NE W! InControl Tbolbox(forms package for Windows; validation functions, date/time, regular expression formatted text control).$210 

PxSQL (SQL for Borland's Paradox Engine; ANSI X3.135-1989 SQL-DML standard; network server not required).$180 

c.pslib (PostScript generation library for C programs; includes complete graphics, font, rotation & paragraph support).$170 

NE W! C/C+ + Libraries by Code Farms (persistent C structures, ER models, dynamic arrays, disk pager, database functions, much .jore).$170 

Viewpoint (C++graphics library; 32-bit color, pattern fill, scroll & bitmap, coordinate tranformations).$170 

Minix Operating System (Version 1.5; Unix-like operating system, includes manual; specify 5.25” or 3.5” diskettes).$150 

NE W! ViewTHeve (relational view of Novell Btrieve databases; includes EZTHeve).$150 

Delorie GCC for MS-DOS (Version 1.05; includes C++, assembler, DOS extender, 387 emulation; complete source code and makefiles) . . $150 

Booter Tbolkit (floppy disk bootstrap routines, DOS file system, light-weight multitasking, windows, fast memory management) .$120 

Dr. MD (runtime memory analyzer & debugger; find many memory corruption errors; examine memory usage).$110 

NE W! 386BSD Version 0.1 & LINUX Version 0.96(two Unix clones for Intel 386).$100 

PC/IP (CMU/MIT TCP/IP for PCs; Crynwr drivers, NFS server, Bdale mailer, PCRoute/PCBridge, NDIS/ODI drivers, Beholder, more) . . . $100 

Demacs (complete GNU Emacs for DOS; needs djgcc to build; based on 18.55).$100 

BASH (key-indexed record management system for DOS and Windows DDL; record locking for concurrent access environments).$95 

NEW! Ibrow (programmer’s Windows-based editor; large files, help, undo/redo, drag-n-drop, function & type tags).$90 

Script Interpreter (a command script interpreter for DOS-based systems; C-like script language; lots of features).$90 

HorC++ (C+ + Class Library for Borland’s Paradox Engine).$80 

VMEM (virtual memory manager by Blake McBride, Version 3.6, LRU pager, dynamic swap file, image save/restore).$80 

CPPCOMM (Version 2.0; C+ + class library for serial communications).$75 

EeeDraw (PostScript display of labeled hierarchical trees; DOS & Windows screen display included; Moen algorithm).$75 

FlexList (doubly-linked lists of arbitrary data with multiple access methods; specify C or C++).$65 

LDB (Loose Data Binder, persistent data objects for C++; handles pointers between objects) .$60 

Kier DateLib (all kinds of date manipulation; translation, validation, formatting, & arithmetic).$60 

Coder’s Prolog (Version 3.0; inference engine for use with C programs).$60 

NE W! PCCTS (Purdue Compiler Construction Tool Set; ported to Microsoft Q like YACC and LEX together with lots of additional features) . . . $60 

MEM. WING (global memory manager for Windows, supports standard C memory allocation calls to "wing” your old C code into Windows) . $55 

BigFloat (arbitrary precision floating point arithmetic and functions; includes BCD conversion).$50 

CALC (ASCII algebraic expression evaluator, unlimited parenthesis nesting, symbols, 32 built-in functions, easily extended).$50 

Backup & Restore Utility by Blake McBride (multiple volumes, file compression & encryption).$50 

Floppy TAR (TAR backup and restore on MS-DOS devices; direct access to non-standard devices) .$50 

SuperGrep (exceptionally fast, revolutionary text searching algorithm; also searches sub-directories).$50 

OBJASM (convert .obi files to .asm files; output is MASM compatible) .$50 

CLIPS Version 5.1 (rule-based expert system generator; advanced manuals available at additional cost).$50 

NIH Class Library & Book (basic C+ + classes & Data Abstraction and Object-Oriented Programmingtn C+ + in softback by Keith Gorlen) . $50 

Editor Pack (19 public domain editors; including microEmacs 3.11, Stevie, Elvis, Moke, mg2a, DTE, Jove, Origami, & GRIEF) .$50 

MicroC C Compiler (retargetable C compiler with optimizer, libraries, and utilities; lots of docs, veiy portable,.$50 

TOUR (beautiful traveling salesman problem solver, finds minimum length paths quickly, includes graphics & plotting programs) .$40 

Charting Routines (Version 1.0; produce many kinds of charts from ASCII data files; rasterized high quality printing feature) .$40 

DES Encryption & Decryption (2500 bits/second on 4.77 MHz PC for on-the-fly encryption at 2400 baud; domestic distribution only) .... $40 

NE W! COPS (poor man’s C++; C macro package which implements C+ + in C).$35 

RXC & EGREP Version 2.0 (Regular Expression Compiler and Pattern Matching; finite state machine from regular expression).$35 

Database Pack (9 databases - simple to complex: isam, bplus, AVL, SDB, ID, gdbm, Requiem, Ingres89, Postgnes).$35 

Bison & BYACC (YACC workalike parser generators; documentation; includes C and C+ + grammars) .$35 

Spell Pack (6 spelling programs, a hyphenator, 2 utility packs and a 60K word list: Ispell, Microsp, Sp, Cspella, Spell, Dawg, Soundex) .... $30 

NEW! Alloc-GC (a garbage-collecting memory allocation library).$30 

REGX Plus (Version 2.0, search and replace string manipulation routines based on regular expressions) .$30 

GNU Awk & Diff for PC (both programs in one package).$30 

Big Number Pack (7 arbitrary precision arithmetic packages in C, one in Fortran but free Fortran-to-C converter is included) .$30 

Crunch Pack (30 file compression & expansion programs; now includes portable ZIP).$30 

UUPC Pack (UUCP for the PC; UUPC Version 1.11Q by Wonderworks and smail/PC Version 25 by Stephen G Trier).$25 

PERL for MS-DOS (Version 4.019; C, sed, awk, and shell all rolled into one language; includes hardcopy docs).$25 

I cl Version 6.1 (Tbol Command Language; add shell programming capability to any command line; elegant command line language) .... $25 

FLEX (fast lexical analyzer generator, new, improved LEX; BSD Version 23.6 with docs) .$25 

GNU RCS (FSFs version of the Revision Control System; like Unix's SCCS only better; keeps track of software development).$20 

PCAL Personal Calendar (generates PostScript calendar for any month or year, lots of options, personalization file for your dates & schedule) $20 

Publisher’s Interchange Language (PIL Tool Kit, Version 5.0, API 20 by Quark) .$20 

NE W! NetCDF (Network Common Data Form; general-purpose data exchange for scientific data; many tools and programs available).$20 

Data 

Moby Thesaurus (25K root words, 1.2M synonyms).$350 

Moby Part-of-Speech (200,000 words and phrases described by prioritized part(s)-of-speech).$120 

Moby Words (500,000 words & phrases, 9,000 stars, 15,000 names).$80 

Moby Shakespeare (plays, sonnets, etc.... every last word).$60 

Dictionary Word List (234,932 words in alphabetical order).$60 

Roget’s 1911 Thesaurus.$40 

U. S. Cities (names & longitude/latitude of 32000 U.S. cities and 6,000 state boundary points).$35 

CIA World Bank II Database (13MB of maps, 5.7M vectors; coastlines, rivers, political boundaries; Africa, Asia, Europe, N. & S. America) $35 

The World Digitized (100,000 longitude/latitude of world country boundaries) .$30 

Lots ’O Words (160,086 German, 178,430 Dutch, 61,843 Norwegian, 60,453 Italian, 138,257 French, 53,142 English) .$30 

Tbtt Pack (1990 CIA World Fact Book, Hacker’s Jargon File, Acronyma, Koran, Mormon Scriptures, One Liners, Mnemonics, more) .... $25 

CD-ROMs 

FontMaster Library (soft fonts for HP and HP compatible laser printers, 36 different type faces; 5,200 bit mapped fonts; 300MB).$70 

InfoMagic (X11R5, Tihoe 4.3 BSD, complete GNU, ISODE, KA9Q & NCSA TCP/IP, all TCP/IP docs, DOS tools; 600MB).$70 

Prime Tme Freeware (over 1 gigabyte of Unix C code).$60 

American Business Phone Book (telephone numbers of 9.2 million businesses by type, geography, and name).$50 

Walnut Creek X11R5 and GNU (X11R5 with contributed and comp.sourcesx, 120 GNU programs, SPARC executables).$35 

Wfclnut Creek Usenet and Simtel Unix-C (600MB).$35 

Walnut Creek Simtel 20 MSDOS Archive (C source code but lots of other stuff too).$20 


11100 Leafwood Lane much more ... ask for catalog FAX: (512) 258-131,2 

Austin, Texas 78750-3587 USA E-mail: info@acw.com 

Free surface shipping for cash in advance For delivery in Texas add 7% MasterCard/VIS A 
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A TRUE SPREADSHEET 
CONTROL! 


(THIS IS NOT A GRID!) 


Drover’s Professional 
ToolBox for Windows 

With 23 custom controls, including Far- 
Point’s industry unique full-featured 
spreadsheet control (not a grid!), For¬ 
matted Edit Controls, Tool Bar and 
Status Bar, ability to add 3D effects to 
dialog boxes, View Pictures with anima¬ 
tion, and Enhanced Listbox this package 
is a developer’s dream come true. 

Over 300 functions are built in, including 
DOS System functions, Date/Time sup¬ 
port, String functions, and Enhanced file 
support. 

Drover’s Professional Toolbox supports 
MSC 7.0, Borland C + +, Turbo Pascal, 
Actor, WindowsMaker Pro, Borland 
Resource Workshop and Dialog Editor. 

Drover’s Professional Toolbox for Win- 
dows is only $345.00. There are no 
royalties and of course you receive our 
30 day no-hassle, money-back guar¬ 
antee. 


DON'T CHEAT YOUR END 
USER WITH A GRID WHEN 
YOU COULD BE GIVING THEM 
A TRUE SPREADSHEET 
CONTROL. 

FarPoint’s Spreadsheet control is unparalleled 
by any other package in its features, flexibility 
and power. The spreadsheet may be optionally 
locked so the user cannot make any changes. 
The width and height of columns and rows may 
be changed by the programmer or by the user. 
The font, color, and data type may be changed 
for any row, column or cell. Cells can have the 
following data types: edit, date, time, integer, 
float, static, formatted pic, combo box, button, 
and picture. Formulas can be added to any cell. 
Editing is performed within the cell. 

CALL OR FAX FARPOINT TODAY: 

( 614 ) 765-4333 

Fax: (614) 765-4939 


Mint 


Visual Architect 

for Visual Basic 

“Visual Architect™ is a product 
that no serious Visual Basic devel¬ 
oper can do without.” 


Along with the industry’s 
most powerful and flexible 
true Spreadsheet custom 
control (not a grid!), Visual 
Architect™ features Date 
with Calendar, Time, Float, 

Integer, Formatted PIC and 
View Text controls. 

The Visual Architect™ 
manual is professionally writ¬ 
ten and contains extensive 
documentation. 

Visual Architect™ is only $245.00. 
There are no roy alities and of course you 
receive our 30 day, no-hassle, money- 
back guarantee. 
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From 

the Editor 


I enjoyed meeting both current and future subscribers at the Windows 
and OS/2 conference in Boston this August. As you might expect, one 
popular question at this conference was whether to develop for Windows 
or for OS/2. As you might also expect, the answer at our booth was usually 
“Windows.” Normally, one makes predictions about the coming year in the 
January issue, but there were lots of predictions about the future at this 
conference, so I want to record mine now for posterity. 

First, when will Windows NT ship? Microsoft’s ostensible ship date is by 
the end of this year, but the trade magazines run blazing headlines such as 
“Windows NT May Ship Late." I am not sure why this sort of speculation 
deserves headlines-, I am not acquainted with any major operating systems 
that have shipped on time, and I have not personally participated in any 
projects of more than 100,000 lines of code that finished anywhere close to 
their deadlines. Therefore, putting one finger to the wind, I predict that 
Windows NT will officially ship on March 15th, real boxes will arrive at my 
local Egghead on March 25th, and the initial shipment will be sold out by 
March 31th. 

Second, who will win: Windows NT or OS/2 2.0? Neither, of course. The 
correct question is: who will have what market share? I predict that by the 
end of 1993, the PC GUI pie will offer 15 percent for OS/2 2.0 (mostly cor¬ 
porate customers), 25 percent for Windows NT, 50 percent for Windows 3.1 
(including Win32s), and 10 percent for “other.” This prediction will be pretty 
hard to prove or disprove, as demonstrated by the latest wrangling about 
how many legitimate copies of OS/2 2.0 have been sold and how many sold 
copies of Windows 3.x are actually in use. 

On the other hand, I don’t really care precisely when Windows NT ships. 
Nor do I care whether OS/2 2.0 ends up with precisely 15 percent, 5 per¬ 
cent, or 25 percent of the market. The operating systems wars create op¬ 
portunities on all fronts, and there will be enough work for everyone. In 
other words, I predict that 1993 will be a very good year to be a Windows 
programmer. 


Ron Burk 

Editor 

CIS: 70302,2566-, BIX: rlburk-, Internet: ronb@rdpub.com ("... !uunet!rdpub!ronb") 
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LEADTOOLS — Developer toolkits for image management. 


Enhance your applications with functions that: 

• Compress images up to 255 to 1 and maintain maximum 
quality 

• Decompress images to video memory or supported file 
formats 

• View supported image files on VGA, Super VGA, and 
TARGA 

• Find optimal 256 color palettes for 16-, 24- and 32-bit images 

• Convert between most popular image formats 

• Flip, rotate, reverse and resize images 


LEADTOOLS' Compression and decompression functions support 
JPEG, JTIF and JFIF formats and LEADS's CMP format. LEAD'S CMP 
format offers greater compression ratios and superior image quality. 
These functions allow decompression of a compressed 24-bit file to 
24-bit mediums as 24-bit true color as well as 8-bit medium at 8-bit 
256-colormapped without sacrificing image quality. Therefore, one 
compressed file supports both 24-bit and 8-bit devices. The same 
image can be displayed on TARGA, VGA and Super VGA. 
Images can be resized "on the fly" for optimal display on any 
screen. LEADTOOLS supports most popular Super VGA 
chipsets. 

All functions support TGA (8,16,24 & 32bit), TIFF (8 & 24bit), 
BMP (4,8, & 24bit), PCX, GIF, JTIF, JFIF, and CMP file 
formats. Images can be stored in XMS, EMS, or swapped to 
disk. A well-defined handle provides access to LEAD'S 
functions for image file formats not currently supported. It 
can also be used to access graphics cards and printers not 
currently supported. 


LEADTOOLS 

Includes all LEADTOOL features. Supports MSC, TC, BORLAND C 
compiliers. Call for a current list of supported compiliers. 

LEADTOOLS - Window DLL 

Includes all LEADTOOL features and a 256-color palette editor. 
LEADTOOLS - no compression 

Includes all LEADTOOL features except compression. Supports 
MSC, TC, BORLAND C compiliers. Call for a current list of 
supported compiliers. 

LEADTQOLS -Windows DLL no compression 
Includes all LEADTOOL features and a 256-color palette 
editor. Does not support compression. 


1 - 800 - 637-4699 In North Carolina call 704-549-5532 


Don't Deflate Your 

Image. 


LEAD Technologies, Inc. • 8701 Mallard Creek Road • Charlotte, NC 28262 

All product names are trademarks of their respective companies. 
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Understanding ROPs 



Charles Mirho 


Most graphics libraries depend upon a good deal of implicit information. For ex¬ 
ample, when you call a function to draw a line, you do not expect to have to specify 
the line color, the line width, and the line style. Instead, you set these properties 
independently and the graphical software applies them implicitly when you draw 
the line. In Windows, a device context contains those implicit properties that alter 
the behavior of drawing functions. 

One of the important device context properties that you can control is the draw¬ 
ing mode. The drawing mode determines how the Windows device driver decides 
what color to make each pixel that it draws. In the most obvious case, you simply 
want the device driver to set the pixels to whatever pen color or text color you 
have selected. However, what if you want to draw a circle that will be visible no 
matter what is already on the screen? If you draw a black circle and parts of the 
screen are black, parts of the circle will be invisible. What if you could draw a black 
circle, but tell the device driver to switch to white when drawing on the black 
portions of the screen? You can do this and more with “raster operations,” or ROPs. 
This article helps you understand ROPs and the special graphics effects you can 
achieve with them. 

Binary ROPs 

Raster operations are logical rules for combining input bits to produce an output 
bit. Binary ROPs are the easiest to understand and are illustrated in Figure 1. As this 
figure shows, the Windows ROP combines the pixel you want to draw (the source 
pixel) with the pixel already on the display (the display pixel). Windows uses the 
resulting value as an index into the color table to arrive at the final color to draw. 
For the moment, I will ignore the extra complexity of color pixels and just assume 
you are dealing with a monochrome display, where each pixel is either 1 (white) or 0 
(black). 


Charles Mirho is a consultant specializing in graphics and multimedia. He can be 
reached via CompuServe at 70563,2671. 
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Given a monochrome environment 
where each pixel is a single bit, there 
are four possible combinations of 
source and display bits. Figure 2 shows 
a logic table, a compact notation for il¬ 
lustrating a logical equation, which is all 
that a ROP is. To use the logic table, lo¬ 
cate the column that corresponds to 
your source bit (0 or 1) and the row 
that corresponds to your display bit (0 
or 1). The box at that row and column 
contains the result bit that this par¬ 
ticular ROP will produce for that input 
Figure 2 shows just one binary ROP, 
but there are fifteen other possible 
results of combining a source and dis¬ 
play pixel and Windows has a name for 
each of them. Figure 3 shows the ROP 
that Windows calls R2_BLACK. The rule 
for ROP R2_BLACK is simple: regardless 
of the values of the source and destination bits, the output bit 
is 0. Since this ROP is easy to understand, it is a good example 
to use to explain how ROPs work with color 


Figure 1 Binary ROPs in Windows 


color table 



Figure 2 A logic table 


ROPs versus Color 

Windows lets you specify display colors as 24-bit RGB 
values, but currently most color video devices cannot display 
that many different colors at once. For example, a video 
device that supported 24-bit color for a 1,000 by 1,000 pixel 
display would require about 3Mb of video memory (three 
bytes of color information for each pixel). In order to provide 
device independence, Windows lets your program ask for any 
24-bit color, but it then maps it to the closest color available. 

The color table is central to Windows' management of 
device-independent color. Figure 4 shows how Windows 
usually arranges the first 16 entries in its color table (most 
color video devices can support at least 16 different colors 
simultaneously). This is the familiar 4-bit color mapping used 
with text-mode color on the PC. 


Figure 4 The default Windows color table 
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80 
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FF 
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FF 
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1111 


FF 

FF 
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Color table index RGB Values 
(base 2) ( hex ) 


0 1 


0 

1 

1 

1 


If S=0 and D=0 then R=0 
If S=1 and D=0 then R=1 
lfS=0andD=1 then R=1 
If S=1 and D=1 then R=1 


The nice thing 
about this table 
is that its arran¬ 
gement helps 
you think in 
terms of real 
colors instead of 
indexes. Each bit 
in the color table 
index represents 
the presence or 
absence of one 
of the component colors, red or green or blue, and the 
presence or absence of intensity. The presence of intensity 
simply lightens the color. So, for example, you get black by 
turning off all four bits: red, green, blue, and intensity. This is 
more intuitive for most people than memorizing "the color at 
index 0000 is black.” The color white (at the bottom of the 
table) is the presence of all component colors and intensity 
(1111). Dark cyan is the presence of green and blue without 
intensity (0011). Light cyan is green and blue with intensity (1011). 

This conceptualization weakens somewhat in the middle of 
the table, where the grays are. Here, dark gray is represented 
as the presence of all component colors without intensity, but 
pale gray is the absence of all color but with intensity. Aside 
from this anomaly, however, the IRGB concept parallels the 
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physical world quite closely. A painter who wanted cyan 
would mix pure green with pure blue, and add lightener (in¬ 
tensity) to get a lighter cyan. To change a dark green pixel 
(0010) to brown, you would turn on the red bit: 

I RGB 

0010 dark green 
0100 red 


0110 brown 

To make a brown pixel yellow, you add intensity: 




Your future^ 
These Windows.^ 



. tranolBt*( cold ): 
itatle BOOL soarch( uold ). 

long do_trarislation( LPSTR pattorn. LPSTR roplai 
itatle long acrap oporation( BOOL cutting ); 


i wi rrlit™ The professional Programmer’ 
VAJUlt W 1 lgl 11 Editor for Microsoft Windows. 


Today, more developers and programming groups 
are turning to Codewright as their vehicle to the 
future — a future developing in Microsoft Windows. 
You can configure and extend Codewright to work 
the way you work, the way your group works. At 
the same time, Codewright is truly at home in the 
Windows environment. 

Codewright has features to make 
even the best editors envious: Hex 
Edit, Selective Display, Multi-file 
Search and Replace, Difference 
Analysis, Customizable Tool Button 
Bar and Tool Box, File Merging and 
ChromaCoding. We’ve included the 
features you have come to rely on, 
too: Unlimited Undo/Redo, Column 
Marking, Language Templates, 

Compile and Find Errors. And 
Codewright has unsurpassed support 
for Windows v3.1. 

You configure Codewright to your 
preferences through its extensive 
system of dialogs, or by editing its 
initialization file. 


You extend Codewright through Dynamic Link 
Libraries (DLLs). Forget those half-hearted C 
macro languages. We provide the C source code 
to our DLLs for you to modify as you please. Or 
you can use any of Codewright’s 600 functions 
in your own DLL that you create with any 
Windows compatible language. 


Command Sets 

jitjffji pim 

Support for 


I RGB 

0110 brown 

1000 intensity bit 

1110 yellow 

All this only works if the color table is arranged as in Figure 4. 
It would not work, for example, if brown were at the index 
0001 instead of 0110. You also have to know that, although 
Windows lets you specify colors as either 24-bit RGB values or 
offsets into the color table, ROPs operate on the color table 
offsets. Therefore, code that uses ROPs typically depends on a 
specific color table organization, and changing the color table 
may break the code. 

Earlier, I mentioned R2_BLACK, which 
is a simple Windows binary ROP that 
produces 0, no matter what the source 
or destination bits are. Suppose that 
you use SetR0P2() to set the drawing 
mode to R2_BLACK and then draw a 
dark pink 4-bit pixel on top of a brown 
pixel. With color pixels, the ROP com¬ 
bines each bit position in the pixel to 
produce, in this case, a pixel whose bits 
are all zero, which maps to black in the 
color table. So, just as in the case of 
monochrome, this R2_BLACK apparently 
maps every color to black. 

R2_BLACK does not actually map 
every color to black; it maps every color 
to the color in position 0000 of the 
color table, which happens to be black 
in this example. As noted earlier, the 
result of a ROP is essentially a function 
of the contents of the color table (if 
green were at index 0000, R2_BLACK 
would map every color to green). Thus, 
if you plan to use ROPs, you must be 
able to count on having a specific color 
table mapping. 

Table 1 shows the logic diagrams for 
all 16 ROPs. Beneath each diagram I 
have written the corresponding logic 
rule and the name Windows assigns to 
the ROP. 



To see your future in Windows, you 
don’t need a crystal ball. Just give 
us a call. You’ll be talking to 
people responsible for highly 
acclaimed software, documentation, 
and support. We'll arrange for you 
to try Codewright without risk, and 
we’ll tell you about a support policy 
and multi-user pricing designed for 
your future. 

Premia and Codewright are trademarks ol Premia Corporation. 

W&AM 

Single-User £0/1 Q Five-User £QQC 
License: License: 


/turns* & 

9 Premium Quality Software 

1075 NWMurray Blvd., Suite 268, Portland, Oregon 97229 USA Fax: (503)647-5423 Phone: (503)647-9902 

□ Request 136 on Reader Service Card □ 


ROP Examples 

ROP R2_BLACKs uses are readily ap¬ 
parent; for some of the other ROPs 
shown in Table 1, some examples will 
help. Consider the second rule in the 
table, R2_MASKPEN. This ROP's rule can 
be expressed as R = S & D, using C 
notation; it effectively ANDs the two 
bits together. Suppose you apply this 
ROP to a specific case: combining a light 
blue pixel with the 16 colors from the 
table. The results are shown in Figure 5. 
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Wi ndow s Tools 

■ 3D Chart 


■ Table 

-Column & row split windows 
Multiple row/ column selections 
-Check boxes/ radio buttons/ 
bitmaps/ editable & combobox 
column 

-Input Validation 
- Color customization 


■ Status Bar 

-Auto scrolled text 
-Stretchable field width 
-Colored progress bar 
-Show date/time & key states 

■ Toolbox 

-Creates buttons from bitmaps 
or text 

-Supports scrolling 
-3D buttons w/color customization 
-Single/ multiple/ no-state button 
groups 

■ Ribbon / Icon Bar 

-3D items w/ color customization 
-Supports combobox, text & 
buttons 


R=0110 (brown) R=1110 (yellow) 

You can easily construct the logic table that produces these 
two effects by looking at each column of bits. Start with an 
empty logic table. The first column of bits says that when S=0 
and D=1, R=0, so place a 0 (the result bit) in column 0, row 1 
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1 

0 

0 

1 


S=0110 (brown) S=0110 (brown) 
D=llll (white) D=0001 (dark blue) 


1 

0 

0 

0 


R-0 

R2_BLACK 


R.-SSD 

R2MASKMOTPEN 


fl.-(S|0) 

R2_NOTMERGEPEN 


Notice that black, dark blue, pale 
gray, and light blue areas of the display 
will be left unchanged. Think about 
how useful R0P_MASKPEN might be on a 
display containing only white, light red, 
black, and dark blue. If a user were to 
draw in light blue on this display, the 
markings on the red and white areas 
would appear light blue, while the 
black and dark blue areas would 
remain unchanged. The pen would 
seem to magically “disappear” when it 
passed over the black and dark blue 
areas, which might be the colors used 
to display crucial information. 

One quite useful rule in Table 1 is 
R2_X0RPEN. Figure 6 shows what hap¬ 
pens when the color white is combined 
with the 16 colors using R2_X0RPEN. 

R2_X0RPEN replaces every dark pixel 
with a light one and vice versa, yielding 
a highly visible contrast. Furthermore, 
applying the R2X0RPEN operator a 
second time will exactly reproduce the 
original colors, “undoing” the line. You 
can see a popular application of this 
ROP every time you resize a Windows 
window. When you resize the window, 

Windows displays a “rubber band" rec¬ 
tangle that stretches or shrinks as you 
move the mouse cursor. Each time you move the mouse, 
Windows has to put back the pixels that were under the rec¬ 
tangle and redraw the rectangle at its new size. R2_X0RPEN 
restores the pixels that were beneath the rectangle without 
having to save them away in a bitmap. 

Flere’s another application. Suppose you have a picture of a 
beach on the display. The sand is white, while the ocean is 
dark blue. You want pixels drawn on the beach to appear 
brown. Pixels drawn on the ocean should appear yellow. 
Without knowing the exart borders of ocean and beach, this 
might seem a difficult problem. Using ROPs makes it easy. First 
form a logic table using an arbitrary color for the source pixel 
— brown was chosen here. The color table index for brown 
(base 2) is 0110. The goal then is to find a ROP that produces 
brown (0110) from brown (0110) and white (1111), and that 
produces yellow (1110) from brown (0110) and dark blue 
(0001). Phrased another way, you need a ROP that produces 
these results: 


Table 1 Windows binary ROPs 


R-S4D 

R2_MASKPEN 


R»SA-D 

R2_MASKPENNOT 


R=D 

R2_NOP 


R»S A D 

R2_XORPEN 


R--(S A D) 

R2_NOTXORPEN 


R--D 

R2_NOT 


1 

0 

1 

0 


1 

0 

1 

1 


1 

1 

1 

0 


R2_NOTCOPYPEN 


R-~S|D 

R2_MERGENOTPEN 


R«~(S&D) 

R2_NOTMASKPEN 


-Over 30 Chart styles 
-Rotation & Scrolling 
-Supports printing & clipboard 


Consulting & Contract Programming Available 
• • Kansmen Corporation • • • 

Tel: (408) 988 0634 Fax: (408) 988 0639 


■ Field Validation 

-Validates date/time/number 
fieldsand "PIC" statements 


All With Source. Royalties Free. 
30 Day Money Back Guarantee. 


0 

1 

0 

1 


R«S 

R2_COPYPEN 


0 

1 

1 

1 


R=S|D 

R2_MERGEPEN 


1 

1 

0 

1 


R-SJ-D 

R2_MERGEPENNOT 


1 

1 

1 

1 


R-1 

R2_WHITE 


October 1992 


Windows/DOS Developer’s Journal — Page 9 




















































































































Figure 5 Effect of R2_MASKPEN on light blue 
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of the logic table. If you continue to fill out the logic table, the 
result will be the same as R2_MERGEPENNOT in Table 1. 

Now suppose you want pixels drawn on the beach to ap¬ 
pear brown and those drawn on the ocean to appear white. 

S=0110 (brown) S=0110 (brown) 

D= 1111 (white) D=0001 (dark blue) 


R=0110 (brown) R=1111 (white) 


As you construct the logic table, you 
reach a conflict. The first column of bits 
requires that when S=0 and D=1, R=0. 
But the last column requires exactly the 
opposite result (R=1). 

This shows that with the color table 
in Figure 4, it is impossible to find a bi¬ 
nary ROP to combine brown with white 
to yield brown, and brown with dark 
blue to yield white. Though I did the 
analysis for a brown source pixel only, 
it holds true for other colors as well. 
Verify this yourself, using a logic table 
for a source pixel of any other color. 
The general rule to remember is this: 
when only one pairing of colors con¬ 
tributes both a 0 and a 1 to the same 
cell of the logic table, selecting another 
source pixel may eliminate the problem. However, when the 0 
and 1 are each contributed by different pairings, as in this 
example, changing the source pixel will not solve the problem. 
Here, the 0 was contributed by the brown-white pairing, and 
the 1 by the brown-blue pairing. You could rearrange the 
color table to make this combination work using binary ROPs, 
but that could cause other problems. 

Here is a concrete example of setting the drawing mode in 
Windows: 



Elle Edit Code Hun Window tie Ip 


^WINDOWSWIASANDY BMP 


Dazzle/VB Demo - TemTuch. Inc. 1992 


PicY 

Hod 

ShuwMndn 
I Sliotch 


Elf noli 


New Dazzle/VB image control! 
Just $99 until 11/30/92! 


Display realistic 256 color images in Visual Basic! 
Break VB's 16 color barrier! Effortlessly zoom, pan and 
adjust colors using custom control properties! 
Dazzle/VB is the only true image display custom 
control for VB. This means that you can get your 
Windows app started without programming! But when 
you need to program for greater control, you can! And 
til 11/30/92 you can save $200 off Dazzle's list price! 
For math, financial and comms VB products call now: 

t Tera Tech 

Tools tor Programmers 

3 Choke Cherry Rd #360, Dept 159, Rockville MD 20850 
Int’l: +1(301)330-6764 Fax:(301)963-0436 BBS: (301)963-7478 
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hDC = GetDC (hWnd); 

SelectObject (hOC, GetStockObject(WHITE_PEN)); 

SetR0P2 (hDC, R2_X0RPEN); 

Ellipse (hDC, xl, yl, x2, y2); 

This code creates a device context for the screen, selects a 
white pen into it, and sets the ROP for the device context to 
R2_X0RPEN. It then draws an ellipse with a white pen. Every 
white pixel of the pen will be XORed with the pixels on the 
screen in the shape of an ellipse. 

Higher Order ROPs 

It is possible to extend the concepts of ROPs to more than 
two bits. For three bits (ternary ROPs), each logic table has 
eight positions and there are 256 possible ROPs. You can use 
ternary ROPs to achieve effects that are impossible with bi¬ 
nary ROPs. 

For example, suppose you want to draw a black-and-white 
picture on an all-white display. When the picture is displayed, 
you want the black portions to appear in blue: 

S=0000 (black) S=llll (white) 

D=1111 (white) D=1111 (white) 


R=0001 (blue) R=1111 (white) 

The logic table for a binary ROP to perform this function (see 
Figure 7) contains an invalid cell. Furthermore, you cannot 
select different colors for the source pixels, since they are 
fixed in the picture you want to draw. 
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The X’s in the logic table in Figure 7 
mean that you don't care whether a o 
or 1 goes there, because that particular 
combination does not appear in the 
problem. Since you don't care what the 
X’s are, they are typically replaced with 
1’s for convenience when evaluating 
the table. In any case, the table con¬ 
tains an invalid cell. 

However, by adding an intermediate 
third color (called the mask color), you 
can construct a ternary logic table that 
produces the desired results. 

S=0000 (black) S=llll (white) 
M=0001 (blue) M=0001 (blue) 

D=llll (white) D=1111 (white) 


R=0001 (blue) R=1111 (white) 


Figure 6 Effect of R2_XORPEN on white 
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BitBlt() are the source bitmap, the destination display, and 
the brush currently selected in the destination device context. 
Here is the Windows code for performing this ternary ROP: 


The resulting ternary logic table is shown in Figure 8. Note 
that the mask color must be selected carefully (as the blue 
mask was here) to avoid creating problems in the table. The 
rule can be expressed as R = ~0 | M | S; however, Win¬ 
dows and Program Manager have adopted a scheme which 
spares the developer the inconvenience of evaluating logic tables. 

Ternary ROPs require one more source of bits than binary 
ROPs do. In Windows, you typically use ternary ROPs with 
BitBlt(). The three objects being combined when you call 


DWORD dwROP = 00FD0A0A; 

/* ... */ 

/* Create solid blue brush (mask) */ 
hBrush = CreateSolidBrush ( 
(COLORREF)RGB(O,0,0x80) ); 
SelectObject (hDestDC, hBrush); 
BitBlt (hDestDC, xl, yl, width, 
height, hSrcDC, xlsrc, ylsrc, 
dwROP); 


NRPCRD/3D Solid modeling for Windows 



Includes C++ Source! 


Just$99 

To order call: 1 - 800 - 800-1961 


Powerful, yet easy to use 3D CAD for 
Microsoft Windows. Advanced surface 
creation and editing commands make 
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✓ Cones, spheres, cylinders, hemispheres 

✓ Sweeps, extrusions, cross sections, fillets 

✓ True 3D surface patches 

✓ Hidden surface removal with multiple light 
sources 

✓ User-definable 3D fonts and symbol libraries 

✓ Print wireframe or shaded to any graphics 
printer supported by Windows 

✓ Named layers, 256 color support, multiple 
viewports, and much, much more! 

✓ Includes fully-commented C++ source code 

✓ Supports Borland C++ with ObjectWindows 

✓ Full 30 day money-back guarantee 
✓No royalties 


$Nc 


'Napier Graphics 


3D graphics at a 2D price! 
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Figure 7 Failed logic table for 
blue-black-white problem 
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Figure 8 Ternary logic table 
for blue-black-white problem 
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The ROP was found by taking the contents of the logic table, 
with X’s replaced with 1’s as noted above, as an index into a 
lookup table provided with the programmer's reference, like 
this: 


sSM 

D\ 00 

01 

11 

10 

0 

X 

X 

X 

X 

1 

0 

1 

1 

1 


In other words, once you select the ter¬ 
nary logic operation you want to per¬ 
form, apply it to this table of all pos¬ 
sible combinations of source, mask, and 
destination bits to obtain the 8-bit ter¬ 
nary ROP. That should be the end of it, 
but Windows makes you then look this 
8-bit ROP up in a table and supply 
another 16 bits of information that it 
uses internally in performing the ROP. 

Windows takes ternary ROPs a step 
further by allowing the mask to be a 
pattern instead of a solid color. In our 
previous example, the mask could be a 
pattern of alternating pixels, in which 
case the 1's in the mask would combine as blue with the 
source and display pixels. The 0's in the mask would combine 
as whatever we set the background color to. 

Conclusion 


S= 1 1 1 1 0 0 0 0 
M= 1 1 0 0 1 1 0 0 
D= 1 0 1 0 1 0 1 0 


R= 1 1 1 1 1 1 0 1 = OxFD 
(Look up ROP OxFD SDK manual) 


Binary and ternary ROPs are more than adequate for most 
pixel-oriented graphics functions. Unfortunately, some specific 
color combinations may be impossible, though suitable alter¬ 
natives can usually be found. You can imagine higher-order 
ROPs operating on four or even five bits, though applications 
would be limited to a few elaborate and highly specific cases. 
You can also imagine how the IRGB concept might be ex¬ 
tended to color tables with 256 or more positions, an issue in 
these times of increasingly powerful display adaptors. □ 
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Graphics 



VESA’s VGA BIOS Extension 
(VBE) Standard 

Victor R. Volkman 

Introduction 

When IBM introduced the VGA in 1987, it had a maximum resolution of 640 
horizontal x 480 vertical pixels with 16 colors. The VGA could also reach 320 horizon¬ 
tal x 200 vertical pixels with a 256-color palette. Less than two years later, third- 
party manufacturers began delivering VGA-compatible cards that provided higher 
and higher graphics resolutions. These “SuperVGAs” now support several additional 
graphics modes from 800 x 600 x 16 to 1280 x 1024 x 256 and beyond. Unfortunate¬ 
ly, each manufacturer has taken a different approach to the problems of mode 
initialization, mode resolution, and video memory windows. Even worse, these tech¬ 
nical details are difficult to research, rarely compatible, and subject to change 
without notice. The net result is a learning curve steep enough to discourage even 
experienced developers. Fortunately, VESA has stepped forward to clear the tangle of 
conflicting SuperVGA implementation details and simplify life for the software 
developer. 

y 

What Is VESA? 

The Video Electronics Standards Association (VESA) was born when several 
monitor and graphics adapter vendors met at spring COMDEX in 1989. Their initial 
purpose was to standardize video timing parameters for the relatively new 
SuperVGA 800 x 600 graphics mode. Without standardized video timing parameters, 
monitors require sophisticated synchronization electronics to handle every possible 
implementation of each video mode. The current VESA membership includes more 
than 130 graphics hardware and software vendors including Intel, Microsoft, IBM, 
Compaq, AT&T, and others. VESA has expanded to encompass standardization com¬ 
mittees for SuperVGA graphics, XGA graphics, monitor timing, multimedia, and GUI 
accelerators. Most recently, VESA formed the Local Bus Committee to standardize 
VGA chipset interfaces with direct 32-bit CPU connections on the motherboard. 

One of VESA's most important contributions to graphics software development 
has been the standard VGA BIOS Extension (VBE). In the remainder of this article, I 
cover the history behind today's standard and tell how you can take advantage of 
its deep color support. 


Victor R. Volkman received a BS in Computer Science from Michigan Technological 
University. He is a contributing editor for Windows/DOS Developer's Journal. He is 
currently employed as Software Engineer at Cimage Corporation of Ann Arbor, 
Michigan. He can be reached directlg at the HAL 9000 BBS (313) 663-4173 or as 
vrv@cimage.com on Usenet 
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DOS & WINDOWS SERIAL 
COMMUNICATIONS DONE THE 
RIGHT WAY 

COMM-DRV is a professional serial communication 
library & device driver for DOS & Windows. 

• Desqview, Procomm DOS/Windows, pcAnywhere 
compatible. 

• Support for most smart & Dumb Multiport cards. 

• Link libraries into application or use external TSR. 

• C, Assembly, Quickbasic, Windows SDK support. 

• Full source for X&Ymodem file Xfer, serial com¬ 
munication libraries, & screen/keyboard libraries. 

• Remote screen management with remote ANSI 
emulation (window scrolling, erasing, etc.). 

• Unlimited number of ports active concurrently. 
Bauds up to 115.2K. 

• Real-Time serial port monitor. 

• 16550A, 16450, 8250 auto detection. 

Library Sources, Device Driver, TSR $189.95 

Develop Serial Communication 
Applications In English 

COMM-LOG is a collection of programs & TSRs for 
developing custom applications through our simple 
english like full featured script language. 

• True background X&Ymodem file transfers on 
several ports concurrently. 

• Run several scripts concurrently in the background, 
foreground, or from application. 

• Built in script language debugging support. 

• Complete data logging support. 

TSRs and multiple examples $189.95 

MS-DOS Multitasking Kernel 

MTASK is a robust multitasking kernel for develop¬ 
ing cooperating multitasking TSRs and programs 
with several threads of execution. Full task control, 
including mailboxes, TSR building routines, IPCs, 
task blocking, sleeping, RTC control, much more!!! 


TSRs, Libraries, & Examples $89.95 


Multiport Cards 

Four Port Multiport card w/16450 $110.00 

Four Port Multiport card w/16550A $170.00 

Eight Port Multiport card w/16550A $225.00 
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Evolution of a Standard 

VESA's first graphics software standards venture was a 
simple BIOS extension for initialization of the 800 x 600 x 16 
SuperVGA display mode. This standard (#VS890401) was 
ratified by the VESA membership in August 1989. By Novem¬ 
ber 1989, the SuperVGA committee had updated the standard 
to include both higher and lower resolutions (see Figure 1). 
This new standard, named VBE vl.O (#VS891101), now covered 
resolutions from 640 x 400 x 256 all the way up to 1280 x 
1024 x 256. VBE vl.O also added a half-dozen functions neces¬ 
sary to provide a truly vendor-independent model for 
SuperVGA programming. 

In October 1990, the SuperVGA committee officially 
adopted VBE vl.1 standard (#VS900602). VBE vl.1 added the 
first extended text modes with up to 132 columns of text (see 
Figure 2). Extended text modes, like graphics modes, had been 


How to Contact VESA 

Video Electronics Standards Association (VESA) 

2150 North First St., Suite #440 
San Jose, CA 95131-2020 USA 
Phone: (408)435-0333 
Fax: (408)433-8225 
BiX: VESA 

AOL: Keyword VESA 
CIS: GOVESA 

VESA currently offers several publications of interest to 
developers. These can all be obtained free of charge from 
the VESA office. 

“VESA Standard 800x600 Mode VGA BIOS Extensions: 

VS890401 —April 9, 1989" (no revision number). 

“VESA Super VGA Standard BIOS Extension: VS891101 —Oc¬ 
tober 1, 1989” (later known as VESA vl.O). 

“VESA Super VGA Standard BIOS Extension, Revision A: 
VS900602 —June 2, 1990" (internally documented as 
VESA vl.1). 

“VESA Super VGA Standard BIOS Extension: VS911022 -Oc¬ 
tober 20, 1991" (internally documented as VESA vl.2). 
“VESA Super VGA Programming Guideline for Direct Color 
Modes in VESA —January 10, 1991" (explains direct color 
mode numbering in VESA vl.O through vl.2). 

“VESA Video Cursor Interface: VS911021 —October 20, 

1991" (extends standard mouse and cursor interfaces 
for VESA resolutions). 

“VESA Super VGA Protected Mode Interface: VS911020 - Oc¬ 
tober 20, 1991” (protected mode protocol for invoking 
VESA functions, does not use I NT lOh). 

“VESA VGA BIOS Extension Toolkit” (a diskette containing 
drivers, documentation, and demonstration programs 
from all of the SuperVGA vendors that support VESA. 
Some of the demonstration programs include source 
code. The current toolkit includes material from Appian 
Technology, ATI, Chips & Technologies, Cirrus Logic, 
Everex, Genoa, Orchid Technologies, Paradise, Sigma 
Designs, STB, Tecmar, Trident, Oak, and others). □ 
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another area notorious for vendor-dependent implementation. 
Additionally, VBE vl.1 added new functions to allow for video 
memory buffers larger than the active display area. This 
means the screen window can pan and scroll around the 
video memory buffer. 

The SuperVGA committee announced the latest standard, 
VBE vl.2 (#VS911022), in October 1991. The VBE vl.2 standard 
has added 15 more high-resolution SuperVGA video modes. 
These new video modes support “deep 
color" displays with up to 24 bits of 
color per pixel. VBE vl.2 also includes 
the functions and data structures 
necessary to control the deep color 
modes. 

You can now obtain TSRs which im¬ 
plement VESA functionality from virtual¬ 
ly all SuperVGA adapter vendors includ¬ 
ing: ATI Technologies, Everex Systems, 

Genoa Systems, Orchid Technology, 

Paradise, Sigma Designs, STB Systems, 

Tecmar, and Video 7. Additionally, many 
SuperVGA chipset manufacturers have 
pledged their support for VESA. 

SuperVGA adapters implemented with 
these chipsets can use VESA TSRs: Ap- 
pian Technology, Chips & Technologies, 

Cirrus Logic, Oak Technology, SMOS Sys¬ 
tems, Trident, Video 7, and Western 
Digital. Contact your local dealer for the 
latest drivers. 

New Direct Color Memory 
Models 

The IBM VGA has remained un¬ 
changed since its original release and 
has thus always been limited to a maxi¬ 
mum 256 simultaneous colors. How¬ 
ever, third-party manufacturers have 
been delivering SuperVGAs with up to 
16 million colors since 1990. Conse¬ 
quently, there has been an urgent need 
for an industry standard for deep color 
VGAs. VBE vl.2 has filled this standards 
gap for DOS developers in a timely 
manner. 

In the standard VGA, each of the 256 
colors is defined by an entry in a 
palette lookup table. An entry consists 
of 18 bits defining one of 256K possible 
colors: 6 red bits, 6 green bits, and 6 
blue bits. VESA refers to the number of 
bits per color element as the palette 
width. One approach to increasing the 
number of available colors is to switch 
to a “paletteless” memory model. 

Specifically, VBE vl.2 defines two new 
memory models for deep color: Direct 
Color and YUV. The complete revised 


list of memory models is shown in Figure 3. 

Prior to VBE vl.2, the Direct Color and YUV memory models 
could only be supported under the provisions for vendor- 
specific extensions. VESA issued guidelines for Direct Color ven¬ 
dor-specific extensions as early as January 1991 (see sidebar). 
The original guidelines used the misnomer “True Color" rather 
than Direct Color and have since been amended. 


Figure 1 

VBE graphics mode numbers and RAM requirements 


Mode 

Resolution 

Colors 

Video RAM 

VESA 

Number 

horiz x vert 

Available 

Used 

Level 

lOOh 

640 X 400 

256 

250K 

1.0 

101h 

640 X 480 

256 

300K 

1.0 

6Ah* 

800 X 600 

16 

234K 

- 

102h 

800 X 600 

16 

234K 

1.0 

103h 

800 X 600 

256 

469K 

1.0 

104h 

1024 X 768 

16 

384K 

1.0 

105h 

1024 X 768 

256 

768K 

1.0 

106h 

1280 X 1024 

16 

640K 

1.0 

107h 

1280 X 1024 

256 

1280K 

1.0 

10Dh" 

320 X 200 

32K (5:5:5) 

125K 

1.2 

lOEh 

320 X 200 

64K (5:6:5) 

125K 

1.2 

lOFh 

320 X 200 

16M (8:8:8) 

188K 

1.2 

1 lOh 

640 X 480 

32K (5:5:5) 

600K 

1.2 

111h 

640 X 480 

64K (5:6:5) ' 

600K 

1.2 

112h 

640 X 480 

16M (8:8:8) 

900K 

1.2 

113h 

800 X 600 

32K (5:5:5) 

938K 

1.2 

114h 

800 X 600 

64K (5:6:5) 

938K 

1.2 

115h 

800 X 600 

16M (8:8:8) 

1406K 

1.2 

116h 

1024 X 768 

32K (5:5:5) 

1536K 

1.2 

117h 

1024 X 768 

64K (5:6:5) 

1536K 

1.2 

118h 

1024 X 768 

16M (8:8:8) 

1406K 

1.2 

119h 

1280 X 1024 

32K (5:5:5) 

2560K 

1.2 

11 Ah 

1280 X 1024 

64K (5:6:5) 

2560K 

1.2 

11 Bh 

1280 X 1024 

16M (8:8:8) 

3840K 

1.2 

* Mode 6Ah is equivalent to 102h and appeared prior to VESA vl.O. 


' * Parenthesis indicate (red:green:blue) bitmask sizes respectively. 


Note: many VBE implementations will have additional OEM-specific modes not 
listed here. 


Figure 2 VBE text mode numbers and RAM requirements 


Mode 

Number 

Columns 

Rows 

Video RAM 
Used 

VBE Level 

108h 

80 

60 

9.3K 

1.1 

109h 

132 

25 

6.4 K 

1.1 

lOAh 

132 

43 

11.IK 

1.1 

lOBh 

132 

50 

12.9K 

1.1 

lOCh 

132 

60 

15.5K 

1.1 

Note: many VBE implementations will have additional OEM-specific modes 
not listed here. 
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The Direct Color memory model 
defines a pixel as a weighted color 
combination rather than as an index to 
a palette. Each pixel is composed of a 
bitmask with four bit-fields: RedMosk, 
GreenMask, BlueMask, and RsvdMask 
(reserved). The size of each bitmask 
varies with each mode (see Figure 4) 
and ranges from five to eight bits long 
accordingly. The RsvdMask is allocated 
for the unused bits in a particular mode 
and normally ranges from zero to eight 
bits long. Figure 4 shows three possible 
organizations for 15-, 16-, and 24-bit 
Direct Color memory models. In the 
YUV model, the GreenMask, BlueMask, 
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and RedMask substitute for the Y, U, and 
V components respectively. 

The actual organizations are flexible 
in both the size and position of each 
bitmask. The ModelnfoBlock structure 
as returned by the Return SuperVGA 
Mode Info subfunction (AL=01h) now in¬ 
cludes the exact organization for the re¬ 
quested mode. See Figure 5 for the 
complete revised ModelnfoBlock struc¬ 
ture. 

The new DirectColorModelnfo field 
in the ModelnfoBlock contains impor¬ 
tant information about the exact video 
mode in question. Bit zero tells whether 
the color ramp (palette) of the Digital- 
to-Analog Converter (DAC) is fixed or 


programmable. As you may recall, the 
DAC is ultimately responsible for turning 
a set of bits into an analog level that 
your monitor can understand. If the 
color ramp is programmable, this im¬ 
plies the RGB palette lookup tables can 
be loaded by the standard BIOS Set 
Block of Color Registers function 
(INT lOh, AX=1012h). In standard VGA 
modes, this function can be used for 
dynamic color animation or other spe¬ 
cial effects. However, since the Direct 
Color model is paletteless by nature, 
the uses for programming the color 
ramp are very limited. For maximum 
portability, developers should avoid 
using the color ramp when in a Direct 
Color mode. 

Bit one of the DirectColorModelnfo 
element tells whether the reserved bits 
(RsvdMask) are usable by your applica¬ 
tion. If bit one is true, then your ap¬ 
plication may read and write the 
reserved bits along with the rest of the 
pixel data. The reserved bits could be 
used to store invisible attribute data 
about the image that might normally 
reside in precious conventional 
memory. If bit one is false, the 
SuperVGA implementation denies you 
the ability to read and write these bits. 
Failure to honor this bit could result in 
unpredictable displays. For maximum 
portability, developers should design 
their applications to operate correctly 
with or without using reserved bits. 

New DAC Palette Functions 

VBE vl.2 includes two new functions 
to control the palette width. Figure 6 
shows the revised list of functions and 
the minimum VBE BIOS level required to 
call them. As described earlier, the IBM 
VGA implementation sets the maximum 
palette width at 18 bits total with 6 bits 
in each RGB element. The new Set DAC 
Palette Control function enables the 
width of each primary (RGB) color ele¬ 
ment to be increased to 8 bits or more. 
The purpose is to enable 24-bit color 
definitions in the context of a palettized 
256-color mode. 

This is the primary alternative to 
using paletteless Direct Color models. 
Applications may continue to address 
memory the same way they would in a 
256-color mode, but the palette indices 
actually refer to 24-bit values rather 
than 18-bit values. This method can 
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Figure 3 

Memory models supported by VBE 


Model 

Number 

Model Name 

VBE BIOS Level 

OOh 

Text mode 

1.0 

Olh 

CGA graphics 

1.0 

02h 

Hercules graphics 

1.0 

03h 

4-plane planar 

1.0 

04h 

Packed pixel 

1.0 

05h 

Non-chain 4, 256-color 

1.0 

06h 

Direct color 

1.2 

07h 

YUV 

1.2 

08h 

Reserved for VBE 

N/A 

OFh 



lOh 

Reserved for OEM-specific 

N/A 

FFh 




Figure 4 Some common direct pixel organizations 


MSB 


15 Bits - 5 bits/mask LSB 


X 

5 Red 

5 Green 

5 Blue 


15 


MSB 16 Bits - XGA Style 


LSB 


5 Red 6 Green 5 Blue 


15 


MSB 


24 Bits - 8 bits/mask 


8 Red 


5 Green 


8 Blue 


23 


Note: “X” denotes reserved mask. 


LSB 
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often be incorporated into existing ap¬ 
plications with fewer source code chan¬ 
ges than the Direct Color method re¬ 
quires. Specifically, Set DAC Palette 
Control makes sense for VGA mode 


13h as well as VBA SuperVGA modes 
lOOh, lOlh, 103h, lOSh, and 107h (see 
Figure 1). The Direct Color modes lODh 
through llBh already have implicit 
palette width definitions. 
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Figure 5 Revised ModelnfoBlock for VBE vl.2 


typedef struct mode info block { /* VBE SuperVGA Subfunction Olh 

*/ 

short ModeAttributes; 

/* flags 

*/ 

char WinAAttributes; 

/* Window "A" attributes 

*/ 

char WinBAttributes; 

/* Window "B 11 attributes 

*/ 

short WinGranularity; 

/* Window granularity in Kb 

*/ 

short WinSize; 

/* Window size in Kb 

*/ 

unsigned short WinASegment; 

/* Segment normally at AOOOh 

*/ 

unsigned short WinBSegment; 

/* Segment normally at AOOOh 

*/ 

void (far *WinFuncPtr) (); 

/* shortcut call to Subfunction 05h*/ 

short BytesPerScanLine; 

/* Bytes per scan line 

*/ 

/* Under VBE vl.l and 1.0 - 

these fields are present only 
if bit 1 of ModeAttributes is set: 


Under VBE vl.2 

these fields are all mandatory 

*/ 

short XResolution; 

/* Horizontal resolution 

*/ 

short YResolution; 

/* Vertical resolution 

*/ 

char XCharSize; 

/* Character cell width 

*/ 

char YCharSize; 

/* Character cell height 

*/ 

char NumberOfPlanes; 

/* Number of memory planes 

*/ 

char BitsPerPixel ; 

/* Bits per pixel 

*/ 

char NumberOfBanks; 

/* Number of banks (CGA/Herc) 

*/ 

char MemoryModel ; 

/* Memory model type 

*/ 

char BankSize; 

/* Bank size in Kb 

*/ 

char NumberOfImagePages; 

/* Display page count, vl.l ONLY! 

*/ 

char ReservedB; 

/* Reserved area, do not use! 

*/ 

/* Under VBE 1.2 - these fields are defined ONLY for Direct Color 

and YUV memory models (modes lODh to llBh). 

*/ 

char RedMaskSize; 

/* Red mask size in bits 

*/ 

char RedFieldPosition; 

/* LSB bit position of red mask 

*/ 

char GreenMaskSize; 

/* Green mask size in bits 

*/ 

char GreenFieldPosition; 

/* LSB bit position of green mask 

*/ 

char BlueMaskSize; 

/* Blue mask size in bits 

*/ 

char BlueFieldPosition; 

/* LSB bit position of blue mask 

*/ 

char RsvdMaskSize; 

/* Reserved mask size in bits 

*/ 

char RsvdFieldPosition; 

/* LSB bit position of Rsrvd mask 

*/ 

char DirectColorModelnfo; 

/* Direct color mode attributes 

*/ 

char Reserved[216] 

) ModelnfoBlock; 

/* Reserved area, do not use! 

*/ 


Figure 6 Summary of INT lOh, AH=4Fh Subfunctions 

AL 

Subfunction Name 

VBE Level 

OOh 

Return SuperVGA Information 

1.0 

Olh 

Return SuperVGA Mode Information 

1.0 

02h 

Set SuperVGA Video Mode 

1.0 

03h 

Return Current Video Mode 

1.0 

04h 

Save-Restore SuperVGA Video State 

1.0 

05h 

CPU Video Memory Window Control 

1.0 

06h 

Set/Get Logical Scan Line Length 

1.1 

07h 

Set/Get Display Start 

1.1 

08h 

Set/Get DAC Pallette Control 

1.2 
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The Set DAC Palette Control function returns in BH the 
number of bits per primary color element that it could actual¬ 
ly set. If the SuperVGA is incapable of setting the requested 
width, it will decrease the width to the next lower value that 
it can handle successfully. Although VBE vl.2 does not limit 
the maximum number of bits per primary color element, it 
would be most unusual to have more than 10 bits per 
primary color element. Before calling this function, you should 
check the zero bit of the “capabilities” field in the VGAInfo- 
Block structure to see if this function is supported. 

After adjusting the palette width, your application can load 
the color palette registers with the standard BIOS Set Block 
of Color Registers function (INT lOh, AX=1012h). This BIOS 
function should work with up to 8 bits per primary color ele¬ 
ment. Beyond 8 bits, an OEM-specific approach must be taken 
since the VGA data format specifies one byte per primary 
color element. 

VBE vl.2 also provides the complementary Get DAC 
Palette Control function which simply returns the current 
number of bits per primary color element. The number of bits 
per primary color element is reset to six each time a VGA or 
VBE SuperVGA graphics mode change takes place. 

Conclusion 

The SuperVGA BIOS Extensions vl.2 are a significant 
upgrade to the previous VBE vl.1 standard. These enhance¬ 
ments consist of new Direct Color memory models, deep color 
graphics modes, and DAC palette control functions. The VBE 
vl.2 standard gives DOS developers a fighting chance to 


produce applications which break the VGA 256-color barrier in 
a hardware-independent fashion. If you are developing any 
DOS application which uses graphics, I recommend taking a 
close look to see how VBE can help you. 
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Porting from Winl 6 to Win32 

Tom Haapanen 


As Windows NT and Win32s near commercial availability, the advantage to be 
gained by converting existing Windows 3.x applications to the new environments 
becomes clearer. While Windows NT is intended for servers and high-end worksta¬ 
tions, Win32s will provide a 32-bit API (called the Win32 API ) for Windows 3.1, thus 
vastly increasing the potential market for 32-bit applications. This article addresses 
some of the issues involved in porting an existing Windows application to Win32, 
and in writing new applications to be portable between Windows 3.x and Windows 
NT and Win32s. 

A basic principle underlying Windows NT and Win32s is that any Windows 3.x 
application is eligible for three levels of compatibility: 

• binary compatibility 

Windows NT can run your Windows 3.x executable, even on non-Intel platforms. 
Your program will run, but it will not take advantage of the power and speed of 
the Win32 API. 

• Win32 source compatibility 

The first desirable level of NT compatibility is source-level compatibility. Unlike 
many other systems, Windows actually imposes greater requirements for source 
compatibility than for binary compatibility in terms of application conformance. 


Tom Haapanen is a software engineer at Waterloo Engineering Software, a small 
company specializing in engineering-oriented applications and software development 
for PC-based systems. He has previously worked on a variety of software projects 
ranging from compilers to advertising reservation systems. He can be reached 
through the Internet as tom0mims-iris.waterloo.edu, or by mail at Waterloo En¬ 
gineering Software, 22 Dupont St £., Waterloo, Ont, Canada, N2M 5L8. 
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X-32VM 32-hit DOS Extender 
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• Win32 awareness 

The highest level of compatibility — 
and the ultimate performance —can 
be gained by converting an existing 
application to take advantage of 
Win32's flat memory architecture, 
multiple threads of execution, and 
the variety of available interprocess 
communications mechanisms. 

While the final level of compatibility 
is the most desirable, this article con¬ 
centrates on the second: making your 
Windows 3.x application source-com¬ 
patible with the Win32 API. This ap¬ 
proach provides significantly improved 
performance with relatively low effort, 
while allowing you to remain source- 
compatible with Windows 3.1. I explore 
the main changes required, with some 
concrete (if simplified) examples from 
the Win32 port of MicroEMACS (see 
sidebar). 

32 Bits 

Even apart from the Win32 API, the 
change to a 32-bit environment affects 
many different aspects of a program. 
For example, since Win32 programs 
generally use the flat 32-bit addressing 
models, both segments and the distinc¬ 
tion between near and far pointers are 
now history. Fortunately, you do not 


need to remove such references, as the 
Win32 windows.h file # defines both 
near and far to nothing. 

In addition, when you move from a 
16-bit environment, all your int (and 
unsigned int ) variables change to 32 
bits, effectively becoming equivalent to 
long variables. While this change 
causes many fewer headaches than 
would an attempt to port a 32-bit ap¬ 
plication to a 16-bit environment, you 
should still inspect your code for any 
dependencies on the size of integers. 

Particularly problematic in the shift 
to 32 bits is the conversion of signed 
integers to unsigned integers: for ex¬ 
ample, (unsigned int)(-l) is no 
longer 65535, but 4294967295. Also, a 
logical not operation (~) on an integer 
produces a different value (even if the 
bitmask is the same for the lower 16 
bits) than with a 16-bit compiler. Finally, 
code that takes advantage of integer 
range wrapping (at 32767 or 65535) 
should be revised to take into account 
32-bit integers, which will not wrap 
until 2 or 4GB. 

With a 32-bit flat memory model, 
pointers are always 32 bits long. This 
should not cause portability problems 
except for assumptions about wrapping 
at the end of a segment and typecasts 


MicroEMACS 

Richard Stallman wrote EMACS, a powerful programmers' text editor with 
a high degree of flexibility and extensibility, in the early 1970s. Since then, he 
has written newer, more powerful, and more memory-hungry versions, cul¬ 
minating in GNU EMACS. 

MicroEMACS was started by Dave Conroy in 1985, and soon after taken 
over by Daniel Lawrence. It was intended as a version of EMACS that could 
run on smaller computers, and it has subsequently been adapted to UNIX, 
VMS, MS-DOS, OS/2, Amiga, and Atari ST. In 1991-1992, Pierre Perret created a 
Windows-based interface for MicroEMACS, and then, in mid-1992, with assis¬ 
tance from the author, ported it to Windows NT. 

While microEmacs does not have all the power of GNU EMACS, it is consid¬ 
erably more powerful and flexible than most other editors. The Windows 
version also supports MDI and multiple instances. Best of all, MicroEMACS' 
copyright statement explicitly provides permission for free distribution of both 
source and executable code, except for the purpose of incorporating it into a 
commercial software package. 

MicroEMACS is available from The Programmer’s Room BBS (317-742-5333), 
or by ftp from wuarchive.wustl.edu. MicroEMACS for Windows is also avail¬ 
able from CompuServe (WINADV forum) and by ftp from ftp.cica.in- 
diana.edu. MicroEMACS for Windows NT is available from CompuServe (WIN32 
forum) and by ftp from ftp.cica. indiana.edu. □ 
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of near (16-bit) pointers to WORD (16-bit) 
quantities. In the latter case, the (no 
longer near) pointer will be 32 bits long 
in Win32, but WORD will remain at 16 
bits, causing a loss of data in the as¬ 
signment. 

In Win 16 a handle is always 16 bits 
long, but, like integers and pointers, it's 
a 32-bit quantity in Win32. As with 
pointers, the greatest portability risk is 
caused by typecasts into 16-bit types. 

Message Handling 

Probably the worst obstacle to total 
source compatibility is the changing of 
the type of the first message 
parameter, wParam, to a UINT (from a 
WORD). The old-style declaration of a 
window procedure typically looked like 
this: 

long FAR PASCAL 

WndProc(HWND hWnd, WORD wMsg, 
WORD wParam, LONG IParam) 

For Win16/Win32 portability, the decla¬ 
rations of the wMsg and wParam 
parameters should be revised to 

long FAR PASCAL 
WndProc(HWND hWnd, UINT wMsg, 

UINT wParam, LONG IParam) 

The change in wParam' s type was neces¬ 
sary to accommodate the passing of 32- 


Table 1 Extended GDI 
Functions 


GetAspectRatioFilterEx 

GetBitmapDimensionEx 

GetBrushOrgEx 

GetCurrentPositionEx 

GetViewportExtEx 

GetViewportOrgEx 

GetTextExtentPoint 

GetWindowExtEx 

GetWindowOrgEx 

MoveToEx 

OffsetViewportOrgEx 

OffsetWindowOrgEx 

ScaleViewportExtEx 

ScaleWindowExtEx 

ScrollWindowEx 

SetBitmapDimensionEx 

SetViewportExtEx 

SetViewportOrgEx 

SetWindowExtEx 

SetWindowOrgEx 


bit handles in messages that were al¬ 
ready fully utilizing the capacity of w- 
Param and IParam. As a result, the 
parameters for a number of messages 
have been repacked into wParam and l- 
Param to accommodate the new HANDLE 
size. 

There are two methods of dealing 
with the change in parameter packing. 
The first possibility is to use conditional 
compilation to select the appropriate 
parameter, as in the following example, 
which extracts the control id from a 
WM_COMMAND message: 

#if defined(WIN32) 

id = wParam; 

#el se 

id = LOWORD(wParam); 

#endif 

This method, though, quickly results in 
a message-handling module inundated 
with Uf statements. A cleaner ap¬ 
proach is to use macros; with a macro, 
the call would be something like 

id = GET_WM_COMMAND_ID(wParam, 

1Param); 

where the macro will extract the ap¬ 
propriate portion of the message 
parameters. Listings la and 1b show 
sample macros for the repacked mes¬ 
sages affecting Win16/Win32 portability. 
These macros could easily be further 
expanded to cover decoding the un¬ 
changed Windows messages, providing 
a complete and symmetrical API to 
message decoding. Listing 2 shows a 
sample application of these macros 
from MicroEMACS. 

Parameter packings for two sig¬ 
nificant messages, EM_GETSEL and 
EM_SETSEL, have also been revised. 
EM_GETSEL still returns wStart, wEnd as 
a result, but also accepts pointers to 
DWORD wStart and wEnd in wParam and 
IParam. EM_SETSEL poses a more 
serious risk should you forget to revise 
your code: instead of accepting wStart, 
wEnd in wParam, it takes wStart in w- 
Param and wEnd in IParam. Old-style 
code will almost certainly result in an 
incorrect selection under Win32. 

Finally, the WM_CTLC0L0R message 
has been replaced by a set of mes¬ 
sages for the various control types (for ex¬ 
ample, WM_CTLC0L0RBTN and 
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Listing la Macros: Win16 




Idefine GET EM SETSEL WSTART(w, 1) 

((UINT)LOWORD(l)) 

Idefine GET WM MDISETMENU HMFRAME (w, 1) 

((HMENU)L0W0RD(1)) 

#define GET_EM_SETSEL_WEND (w, 1) 

((UINT)HIWORD(I) ) 

Idefine GET_WM_MDISETM£NU_HMWINDOW(w, 1) 

( (HMENU)HIWORD(l )) 

#define GET EM LINESCROLL VERT (w, 1) 

((UINT)L0W0RD ( 1)) 

Idefine GET WM MENUCHAR CHAR (w, 1) 

((WORD)w) 

Idefine GET EM LINESCROLL H0RIZ(w, 1) 

((UINT)HIWORD(1)) 

Idefine GET WM MENUCHAR HMENU(w, 1) 

((HMENU)LOWORD(l)) 

Idefine GET WM ACTIVATE STATE(w, 1) 

((WORD)w) 

Idefine GET_WM_MENUCHAR_FLAGS(w, 1) 

((WORD)HIWORD(l)) 

Idefine GET WM ACTIVATE HWND (w, 1) 

((HWND)L0W0RD(1) ) 

Idefine GET WM MENUSELECT ID (w, 1) 

( (WORD)w) 

Idefine GET WM ACTIVATE FMIN (w, 1) 

( (BOOL)HIWORD(l )) 

Idefine GET WM MENUSELECT HMENU(w, 1) 

( (HMENU)HIWORD(1 )) 

Idefine GET WM CHARTOITEM CHAR(w, I) 

( (WORD)w) 

Idefine GET_WM_MENUSELECT_FLAGS(w, 1) 

((WORD)LOWORD(I)) 

Idefine GET WM CHARTOITEM HWND(w, 1) 

( (HWND)L0W0RD (1)) 

Idefine GET WM PARENTNOTIFY MSG (w, 1) 

( (WORD)w) 

Idefine GET WM CHARTOITEM POS (w, 1) 

( (WORD)HIW0RD(1 )) 

Idefine GET WM PARENTNOTIFY CHILD(w, 1) 

((HWND)LOWORD(l)) 

Idefine GET WM COMMAND ID (w, 1) 

( (WORD)w) 

Idefine GET_WM_PARENTNOTIFY_ID (w, 1) 

( (WORD)HIWORD ( 1 )) 

Idefine GET WM COMMAND HWND(w, 1) 

((HWND)LOWORD(l)) 

Idefine GET WM MENUCHAR CHAR (w, 1) 

( (WORD)w) 

Idefine GET_WM_C0MMAND_C0DE(w, 1) 

Idefine GET WM HSCROLL C0DE(w, 1) 

( (WORD)HIW0RD(1 )) 

( (WORD)w) 

Idefine GET WM MENUCHAR HMENU(w, 1) 
Idefine GET_WM_MENUCHAR_FLAGS(w, I) 

( (HWND)LOWORD(1)) 

((WORD)HIWORD(1)) 

Idefine GET WM HSCROLL POS (w, 1) 

((WORD)L0W0RD(1)) 

Idefine GET WM VKEYTOITEM CHAR(w, 1) 

((WORD)w) 

Idefine GET WM HSCROLL HWND(w, 1) 

( (HWND)HIWORD(1 ) ) 

Idefine GET WM VKEYTOITEM HWND(w, 1) 

((HWND)LOWORD(l)) 

Idefine GET WM MDIACTIVATE CH ACT (w. 

1) 

Idefine GET_WM_VKEYT0ITEM_P0S (w, 1) 

( (WORD)HIW0RD(1 )) 

( (HWND)L0W0RD(1 ) ) 


Idefine GET WM VSCROLL C0DE(w, 1) 

( (WORD)w) 

Idefine GET WM MDIACTIVATE CH DEACT(w, 

1) 

Idefine GET WM VSCROLL POS (w, 1) 

((WORD)LOWORD(l)) 

( (HWND)HIWORD ( 1)) 


Idefine GET WM VSCROLL HWND(w, 1) 

((HWND)HIWORD(l)) 


UMJCTLCOLORLISTBOX), as the two required 32-bit handles do 
not allow for the passing of the control type. These messages 
must be handled individually; Listings 3a and 3b show a com¬ 
parison of sample color handling code ported from Win 16 to 
Win32. Note that the only changes of consequence are the in¬ 
clusion of all the UMJCTLCOLOR* messages in the outer switch 
statement, and the use of message instead of HIUORD(lParam) 
in the inner switch statement. 

GDI Changes 

The Win32 GDI expands the graphics coordinate system 
from 16 bits to 32 bits to cope with ever larger and higher- 
density output devices. While the parameters to the func¬ 
tions are integers which naturally extend to 32 bits, the 
return value has, up to now, been a DUORD containing the 
packed x and y coordinates. Rather than returning a structure 
containing the two 32-bit values, an additional parameter has 
been added to a number of GDI functions (the functions are 
shown in Table 1): a pointer to a POINT structure to be filled 
with the two 32-bit integers). 

All the changed functions, except for GetTextExtent- 
Point(), have the suffix Ex to indicate that they take an addi¬ 
tional parameter, a pointer to a POINT data structure for stor¬ 
ing the result GetTextExtentPoint() is the exception to this 
naming scheme, and GetTextExtentPointEx() returns addi¬ 
tional text extent information. 

Windows 3.1 includes the new GDI API calls, which were 
not part of the Windows 3.0 API. Fortunately, however, if you 
need to maintain a Windows 3.0-compatible version, you can 
still do so, since the new API is implemented in a static library 
in the Windows 3.1 SDK, and can be used even in 3.0-com- 
patible applications. 

If your code is liberally smattered with MoveTof) calls that 
do not use the return value, you may choose to add the 


macros in Listing 4 to your header files. These macros pass 
NULL as their final argument, indicating that no return value is 
desired, and cast the return value to void, preventing you 
from accidentally using the return value from MoveToEx() — 
which is not a valid point. 

While it would be relatively simple to write a simple, 
general-purpose compatibility layer for Win32 GDI to allow the 
use of old functions, such a layer would incur the risk of 
numeric overflow in both the parameters and return values. If 
you're either certain that your graphics coordinates will never 
exceed -*7-32767 or willing to risk overflow, you could write 
functions similar to those that follow (macros cannot cope 
with a temporary structure). In general, though, you will be on 
much safer ground if you use the macros of Listing 4 instead, 
and update the calls that cause void assignment errors. 

#if defined(WIN32) 

DWORD MoveTo(HDC hDC, int x, int y) 

{ 

POINT p; 

MoveToEx(hDC, x, y, &p); 

return ((MAKEL0NG((short)p.x, (short)p.y)); 

} 

lendif 

Note also that the MAKEPOINT macro has been retired, as a 
POINT data structure can no longer be stored in a DUORD. 

Multiple Instances 

With Win32, each application runs in a separate virtual 
machine with its own address space, making other instances 
(or their window classes) invisible to an instance of the ap¬ 
plication. This change makes the GetInstanceData() function 
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Listing 1b Macros: Win32 


Idefine GET EM_SETSEL_WSTART(w, 1) ((UINT)w) 

Idefine GETjM“SETSEL_WEND (w, 1) ((UINT)l) 

Idefine GET_EM_LINESCROLL_VERT (w, 1) ((UINT)l) 

Idefine GET_EM_LINESCROLL_HORIZ(w, 1) ((UINT)w) 


Idefine GET_WM_ACTIVATE_STATE(w, 1) ((WORD)LOWORD(w)) 

Idefine GET_WM_ACTIVATE_HWND (w, 1) ((HWND)l) 

Idefine GET_WM_ACTIVATE_FMIN (w, 1) ((BOOL)HIWORD(w)) 


Idefine GET_WM_CHARTOITEM_CHAR(w, 1) ((WORD)w) 

Idefine GET_WM_CHARTOITEM_HWND(w, 1) ((HWND)LOWORD(l)) 

Idefine GET_WM_CHARTOITEM_POS (w, 1) ((WORD)HIWORD(1)) 


Idefine GET_WM_COMMAND_ID (w, 1) ((WORD)LOWORD(w)) 

Idefine GET_WM_COMMAND_HWND(w, 1) ((HWND)l) 

Idefine GET_WM_COMMAND_CODE(w, 1) ((WORD)HIWORD(w)) 


Idefine GET_WM 
Idefine GET_Wt( 
Idefine GET WM 


HSCROLL_COOE(w, 1) 
HSCROLL_POS (w, 1) 
HSCROLL_HWND(w, 1) 


((WORD)LOWORO(w)) 
((WORD)HIWORD(w)) 
((HWND)1) 


Idefine GET_WM_MDIACTIVATE_CH_ACT (w, 1) ((HWND)w) 

Idefine GET_WM_MDIACTIVATE_CH_DEACT(w, 1) ((HWND)l) 


Idefine GET_WM_MDISETMENU_HMFRAME (w, 1) ((HMENU)w) 
Idefine GET_WM_MDISETMENU_HMWINDOW(w, 1) ((HMENU)l) 


Idefine GET_WM_MENUCHAR_CHAR (w, 1) 
Idefine GET_WM_MENUCHAR_HMENU(w, 1) 
Idefine GET_WM_MENUCHAR_FLAGS(w, 1) 

Idefine GET WM_MENUSELECT_ID (w, 1) 
Idefine GET_WM_MENUSELECT_HMENU(w, 1) 
Idefine GET_WM_MENUSELECT_FLAGS(w, 1) 

Idefine GET WM_PARENTNOTIFY_MSG (w, 1) 
Idefine GET”WM_PARENTNOTIFY_CHILD(w, 1) 
Idefine GET_WM_PARENTNOTIFY~ID (w, 1) 

Idefine GET_WM_MENUCHAR_CHAR (w, 1) 
Idefine GET_WM_MENUCHAR_HMENU(w, 1) 
Idefine GET_WM_MENUCHAR_FLAGS(w, 1) 

Idefine GET_WM_VKEYTOITEM_CHAR(w, 1) 
Idefine GET_WM_VKEYTOITEM_HWND(w, 1) 
Idefine GET_WM_VKEYTOITEM_POS (w, 1) 

Idefine GET_WM_VSCROLL_COOE(w, 1) 
Idefine GET_WM_VSCROLL_POS (w, 1) 
Idefine GET_WM_VSCROLL_HWND(w, 1) 


((WORD)LOWORD(w)) 
((HMENU)l) 

((WORD)HIWORD(w)) 

((WORD)LOWORD(w)) 
((HMENU)l) 

((WORD)HIWORD(w)) 

((WORD)LOWORD(w)) 
((HWND)1) 

((WORD)HIWORD(w)) 

((WORD)LOWORD(w)) 
((HWND)1) 

((WORD)HIWORD(w)) 

((WORD)LOWORD(w)) 
((HWND)1) 
((WORD)HIWORD(w)) 

((WORD)LOWORD(w)) 
((WORD)HIWORD(w)) 
((HWND)1) 


obsolete, so the call has been deleted. However, since a Win32 
application’s MinMain() will always receive a hPrevInstance as 
NULL, you can safely define a macro to deal with that: 

#if defined(WIN32) 

Idefine GetInstanceData(hInstance, pData, pCount) 
lendif 

Since there will never be any previous instances with Win32, 
GetlnstanceDataf) would never actually be called in a Win32 
environment, so it's safe to transform such calls into no-ops. 

Applications that actually share information by accessing 
other instances' data structures pose a more complex prob¬ 
lem. In the case of MicroEMACS, the instance number was 
stored in an extra window word which was then read by the 
other instances. This type of behavior is clearly unacceptable 
in Win32, so another approach was needed. Initially, we con¬ 
sidered a shared memory solution (using file mapping), but 
since the information to be shared was just a single byte, we 
decided instead to use application-specific messaging. The 
Win 16 and Win32 code fragments for the instance enumera¬ 
tion process are shown in Listing 5. 

Asynchronous Event Queues 

One of the difficulties with multitasking in Windows 3.x is 
the restriction imposed by a single input queue: only one ap¬ 
plication is able to access the keyboard or the mouse at any 
given time. Windows NT avoids this problem by providing a 
separate, asynchronous, input queue for each thread of execu¬ 
tion. Thus, regardless of whether it has crashed or is just in 
the middle of intensive computations, a single application can¬ 
not prevent other applications from receiving input events. 



A change in the semantics for GetFocus() and GetActive- 
Uindowf) has perhaps the greatest impact on existing applica¬ 
tions. In Windows 3.x, these functions always return the handle 
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Listing 2 Message Macro Application 


LONG EXPORT FAR PASCAL 

FrameWndProc (HWND hWnd, UINT wMsg, UINT wParam, LONG 
IParam) 

{ 

/* process the message for the MDI frame window */ 
switch (wMsg) { 

case WM_ACTIVATE: 

/* create caret for iconized MDI child window */ 
EmacsCaret (GET_WM_ACTIVATE_STATE(wParam, IParam)); 
return DefFrameProc (hWnd, hMDIClientWnd, wMsg, 
wParam, IParam); 

break; 

case WM_COMMANO: 

/* process a menu selection */ 
if (IHenuCommand (wParam, IParam)) 

return DefFrameProc (hWnd, hMDIClientWnd, wMsg, 
wParam, IParam); 

break; 
case ... 

) 

BOOL FAR PASCAL 

MenuCommand (UINT wParam, LONG IParam) 

{ 

FARPROC Proclnstance; 

DWORD HelpContext; 

/* select appropriate menu command */ 
switch (GET_WM_COMMAND_ID(wParam, IParam)) ( 

} 



fractal 


Iterated Systems 
5550-A Peachtree Pkwy., Suite 650 
Norcross, GA 30092 
Tel: (404)840-0310 
Fax: (404)840-0806 


•'M 


Uonsider the fern. This intricate plant 
spawned the discovery of 
Fractal Transform™ Technology 
and fractal image compression; today's 
most powerful image compression 
technology. 

Consider POEM ColorBox 
This new SDK harnesses 
fractal technology for 
Windows 3.x developers. 
DLLs provide a complete 
imaging environment 
including ultra-high 
compression, resolution 
independent images, fast 
decompression and high 
quality 24-bit color rendering. 

Whether you program in C or Visual 
Basic, POEM ColorBox is comprehen¬ 
sive, easy-to-use, and at $499, 
surprisingly affordable. 

Call or write today for a free demo 
disk. Learn why POEM ColorBox is the 
solution to your image compression 
needs. 


□ Request 132 on Reader Service Card □ 


Page 24 - Windows/DOS Developer’s Journal 


of the active window, but in Win32 they will return NULL if 
the active input window is not owned by the current thread. 
You should inspect all calls to these two functions to make 
certain that you are not assuming the return of a valid handle. 

The other significant change in semantics is in mouse cap¬ 
ture; while SetCapture() will capture the mouse wherever it 
is on the screen, it will do so only as long as the mouse 
button is pressed. Release of the mouse button ends the cap¬ 
ture and sends any further mouse input to whatever window 
contains the mouse pointer. Further, calling SetCapture() 
while the mouse button is released will capture mouse move¬ 
ment only within one of the windows owned by the capturing 
thread. These changes, while unfortunately changing capture 
behavior, ensure that the user will be able to switch to 
another window at any time, even if mouse movement is 
being captured. 

Interfacing to External Programs 

The only method of external program execution in Win¬ 
dows 3.x was UinExecf). While Win32 supports this basic 
functionality for backwards compatibility, the preferred 
method is to use CreateProcessf). And, since it is possible to 
do a wait on a process object, this functionality greatly 
simplifies calling external processes that must complete before 
execution can continue. While this function is not compatible 


Listing 3a wm_ctlcolor: wini6 


case WM_CTLC0L0R: 

switch (HIWORD(lParam)) { 
case CTLC0L0R_DLG: 

SetBkColor(wParam, RGB(192, 192, 192)); 
SetTextColor(wParam, RGB(0, 0, 0)); 
return((DWORD)hDlgBrush); 
break; 

case CTLC0L0R_BTN: 

break; 
case ... 

) 

break; 


Listing 3b WM_CTLCOLOR: Win32 


case WM_CTLC0L0RBTN: 
case WM_CTLC0L0RDLG: 

case WM_CTLC0L0RSTATIC: 
switch (message) ( 

case WM_CTLC0L0RDLG: 

SetBkColor(wParam, RGB(192, 192, 192)); 
SetTextColor(wParam, RGB(0, 0, 0)); 
return((DW0RD)hDlgBrush); 
break; 

case WM_CTLC0L0RBTN: 

break; 
case ... 

) 

break; 
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with Windows 3.x, it can provide substantial benefits with a 
relatively small effort. 

In MicroEMACS, running external utilities is an essential part 
of the operation of the editor. With Win 16, it's necessary to 
enumerate the top-level windows in order to locate the win¬ 
dow created by the external program and then, at regular 
intervals, check whether that window still exists. With Win32, 
the calling program can choose not to wait, to wait indefinite¬ 
ly, or to wait for a specified amount of time. You should be 
aware, however, that choosing an indefinite wait, as shown in 
the example, will cause your application to ignore all events 
until the external program completes its execution (as noted 
earlier, however, other applications will still receive event 
messages). 

The new API substantially reduces both the size and the 
complexity of the code needed for interfacing to external ap¬ 
plications. 

Other API Changes 

An extra parameter has been added to several Windows 
3.x API calls whose parameters did not include the size of the 
application-supplied result buffer. Like the new GDI calls, the 
revised functions are denoted by the £x suffix. 

SetWindowUord() and GetUindowWordf) now use 32-bit 
values only for the following parameters: 

GWW_HMODULE 

GWW_HWNDPARENT 

GCW_HBRBACKGROUND 

GCW_HCURSOR 

GCW_HIC0N 

GCW_HMODULE 

In all other cases, 16-bit values will be stored or fetched. This 
is a potential problem area, so you must make sure that you 
are not attempting to store handles into the window or class 
structures using SetWindowWord(). 

Finally, a small number of API functions - those dealing 
with segmentation, DOS, or PC specifics such as EMS memory — 
have been removed from the API. These functions are either 
irrelevant in the Win32 environment (such as SetMessage- 
Queue() and LimitEMSPagesO) or superseded by non-DOS- 
specific functions (such as D0S3Cal l () and NetBIOSCal l ()). 

Conclusion 

Converting to Win32 is not quite automatic, but with the 
option of binary compatibility available, it doesn't really need 
to be. Since the changes required are relatively few, a conver¬ 
sion can often be completed in a matter of days, so long as 
the application conforms to the standard usage of the Win¬ 
dows API. And at the end of the process, you will have a true 
32-bit application that can provide greatly improved perfor¬ 
mance over its 16-bit sibling — and be ready to fly on non- 
Intel platforms as well. 
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Listing 4 GDI Backward Compatibility Macros 


#define MoveToEx(hDC, X, Y) \ 

((void)(MoveToEx(hDC, X, Y, NULL)) 

Idefine OffsetViewportOrgEx(hDC, X, Y) \ 

((void)(OffsetViewportOrgEx(hDC, X, Y. NULL)) 
#define OffsetWindowOrgEx(hDC, X, Y) \ 

((void)(OffsetWindowOrgEx(hDC, X. Y, NULL)) 
fdefine ScaleViewportExtEx(hDC, Xn, Xd, Yn, Yd) \ 

((void)(ScaleViewportExtEx(hOC, Xn, Xd, Yn, Yd, NULL)) 
fdefine ScaleWindowExtEx(hDC, Xn, Xd, Yn, Yd) \ 

((void)(ScaleWindowExtEx(hDC, Xn, Xd, Yn, Yd, NULL)) 
Idefine ScrollWindowEx(hDC, dx, dy, IpS, lpC, hrU, IpU, f) \ 
((void)(ScrollWindowEx(hDC, dx, dy, IpS, lpC, hrU, 
IpU, f. NULL)) 

Idefine SetBitmapDimensionEx(hBit, X, Y) \ 

((void)(SetBitmapDimensionEx(hBit, X, Y, NULL)) 
Idefine SetViewportExtEx(hDC, X, Y) \ 

((void)(SetViewportExtEx(hDC, X, Y, NULL)) 
Idefine SetViewportOrgEx(hOC, X, Y) \ 

((void)(SetViewportOrgEx(hDC, X, Y, NULL)) 
Idefine SetWindowExtEx(hDC, X, Y) \ 

((void)(SetWindowExtEx(hDC, X, Y, NULL)) 

Idefine SetWindowOrgEx(hDC, X, Y) \ 

((void)(SetWindowOrgEx(hDC, X, Y, NULL)) 


M 
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Listing 5 Instance Enumeration 


#if !defined(WIN32) 

if ((hWnd != LOWORD(1Param)) && 

(GetClassLong (hWnd, GCL_WNDPROC) ■== 
(LONG)FrameWndProc)) { 
if (HIWORD(lParam) != 0) { 

SendMessage (hWnd, WM_COMMAND, EMACSJROADCAST, 

1Param); 

I 

if (HIW0RD(1Param) == EMACS_STARTING) { 

/•-compute highest application Id */ 

Id = GetWindowWord (hWnd, GWWFRMID); 
if (Id == 0) Id = 1; 

++Id; 

BroadcastVal * max(BroadcastVal, Id); 

) 

else { 

/•-compute number of applications */ 

BroadcastVal++; 

1 

1 

#else /• WIN32 */ 

if (hWnd !* L0W0RD(1Param)) { 
char szClassName[32]; 

if ( strcmp(szClassName, szFrameClassName)) retum(TRUE); 


/* MsgEmacsBroadcast was registered in the 
initialization */ 

rc « SendMessage (hWnd, MsgEmacsBroadcast, 
MAKELONG(EMACS_BROADCAST, 
MsgType), 1Param); 
if (LOWORD(rc) == EMACS_RESP0ND) { 
switch (MsgType) { 
case EMACS_STARTING: 

/•-compute highest application Id */ 
Id = HIWORD(rc); 
if (Id == 0) Id = 1; 

++Id; 

BroadcastVal - max(BroadcastVal, Id); 
break; 

case EMACS_ENDING: 
default: 

/•-compute number of applications */ 
BroadcastVal++; 
break; 
break; 

) 

) 

) 

#endif 
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Listing 6 Running an External Utility 


#if !defined(WIN32) 

WinExec (DOSApp ? FullCmd : Cmd, SW_SH0WN0RMAL); 

Proclnstance = MakeProcInstance ((FARPR0C) 

LaunchPrgEnumProc, 
hEmacsInstance); 

/* LaunchPrgEnumPrg will place window handle in hPrgWnd */ 
EnumWindows (Proclnstance, (DWORD)hModule); 

FreeProcInstance (Proclnstance); 

/* Keep checking for the window every so often, until it 
no longer exists */ 

WaitForLaunchPrg(hPrgWnd); 
lelse 

STARTUPINFO sulnfo; 

PR0CESS_INFORMATION plnfo; 

sulnfo.cb = sizeof(STARTUPINFO); 

sulnfo.wShowWindow = SW_SH0WN0RMAL; 
sulnfo.dwFlags = STARTFJJSESHOWWINDOW; 

if (CreateProcess (NULL, DOSApp ? FullCmd : Cmd, NULL, 

NULL, DETACHEDPROCESS, FALSE, NULL, NULL, 
isulnfo, Splnfo)) 

WaitForSingleObject(pInfo.hProcess, -1); 

lendif 

I 
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■Windows Questions & Answers 
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Windows System Timers; 

Icon Questions; Rotating a Bitmap; 
Handling a Joystick 


Q The following question came up in a dialog with our editor, Ron Burk. He said: 

“In a custom control I’m making, the user may grab selected text, drag it 
elsewhere in the control, and drop it. While dragging it, the user may move the 
mouse off the control in order to cause text to scroll vertically or horizontally. When 
that happens, my control has to periodically scroll its contents. 

"Jeffrey Richter's solution in Windows 3: A Developer's Guide is to just go into a 
loop, waiting for the user to release the mouse button. I did not want to do this, 
because I self-righteously did not want to hog the CPU. Using a timer would solve 
the problem but, like Richter, I don’t want a control that fails if you happen to have 
used up all 16 system timers.” 

A Windows controls that support forms of dragging, such as ListBox and Edit, face 
the same problem, and they use a timer to periodically generate a scroll event 
without hogging the CPU. These controls use an undocumented “system” timer 
rather than a normal timer. Windows has only one system timer, but the Windows 
controls share it cooperatively. A system timer is similar to a regular timer and 
comes from the same finite pool of timers that a regular timer does. The difference 
is that one additional system timer is available after the last regular timer has been 
allocated. 


Paul Bonneau 


Send questions to Paul via Internet 
as bonneauPhyper.hyper.com-, 
from CompuServe: 
>INTERNET:bonneau@hyper. hyper, com-, 
or in care of this magazine at: 

1601 W. 23rd St., Suite 200 
Lawrence, kS 66046-2743. 


Paul Bonneau is the senior software design engineer for Hypercube, Inc, #7-419 Phillip 
St., Waterloo, Ontario, Canada, N2L 3X2. His current project is HyperChem, a molecular 
modelling software package for Windows. Paul has been developing Windows ap¬ 
plications for 5 years. Much of his expertise was gained at Microsoft, where he imple¬ 
mented a library module used by all of Microsoft's major Windows applications. 
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What if other applications use up all the normal timers and 
another application just acquired the last system timer? Since 
the control must have the focus for dragging to occur, and at 
most one window may have the focus at any given time, it is 
always safe to use at most one system timer for the control 
that has the focus. This internal Windows convention allows 
Windows controls to safely use a timer to implement dragging 
types of operations. The Windows controls are careful not to 
assume they still own a system timer if they lose the focus. 

You can create a system timer with SetSystemTimer() 
and release it with KillSystemTimer(). These functions have 
the same return values and parameter lists as their docu¬ 


mented counterparts, SetTimerf) and KillTimer(). One dif¬ 
ference between a system timer and a normal timer is that 
the system timer generates a UM_SYSTIMER message ( 0x0118) 
instead of the normal UM_TIMER (0x0113) when you do not 
specify a callback function. 

Windows 3.0 exported both SetSystemTImer() and Kill- 
SystemTimer() , but Windows 3.1 does not, presumably to dis¬ 
courage their use. This move by Microsoft does not make 
good sense, since these functions are essential for authors of 
custom controls. Hopefully, Microsoft will rethink its position 
so that custom controls can be as robust as Windows' own 


Listing 1 showicon.c - Display an executable or DLL's icons 


linclude <windows.h> 
linclude <conmdlg.h> 
linclude <shellapi.h> 
linclude <memory.h> 
linclude “showicon.h" 


HICON * rgicn; 

int cicn; 

HINSTANCE hi ns; 


// Array of icons. 

// Count of icons in array. 
// Instance of app. 


char szFi 1 ter[] = // File filter list. 

“Executable(*.exe)\0*.exe\0DynaLink(*.dl1)\0*.dl1\0"; 
char szApp[] ■ “Showlcon"; 


V0I0 GetFilelcons(HWND); 

LONG CALLBACK MainWndProc(HWND, UINT, WPARAM, 

LPARAM); 
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VOID PaintWnd(HWND); 

VOID Storelcons(LPSTR); 

int PASCAL 

WinMain(HINSTANCE hinsThis, HINSTANCE hinsPrev, 

LPSTR lszCommand, int wShowWindow) 
/////////////////////////////////////////////////////// 
// - Entry point. // 

/////////////////////////////////////////////////////// 
{ 

MSG msg; 

HWND hwnd; 

bins » hinsThis; 
if (hinsPrev «« NULL) 

( 

WNDCLASS wcs; 

wcs.style = CS_HREDRAW | CS_VREDRAW; 
wcs.lpfnWndProc « MainWndProc; 
wcs.cbClsExtra * 0; 
wcs.cbWndExtra » 0; 
wcs.hlnstance ■ hins; 
wcs.hlcon = NULL; 

wcs.hCursor = LoadCursor(NULL, IDC_ARR0W); 
wcs.hbrBackground ■ (HBRUSH)(C0L0R_WIND0W + 1); 
wcs.1pszMenuName = szApp; 
wcs.lpszClassName = szApp; 
if (!RegisterClass(&wcs)) 
return FALSE; 

) 

if ((hwnd * CreateWindow( 
szApp, 

“Show Icons", 

WS_0VERLAPPEDWINDOW, 

CWJJSEDEFAULT, 

wShowWindow, 

CW USEDEFAULT, 

CWJJSEDEFAULT, 

NULL, 

NULL, 

hins, 

NULL)) — NULL) 
return FALSE; 

ShowWindow(hwnd, wShowWindow); 

UpdateWindow(hwnd); 

while (GetMessage(&msg, NULL, NULL, NULL)) 

( 

TranslateMessage(&msg); 

DispatchMessage(&msg); 

) 

return msg.wParam; 
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system controls. Luckily, you can still access these functions 
by importing them in your .def file: 

IMPORTS 

Ki 11SystemTimer=USER.182 
SetSystemTimer=USER.11 

I obtained these ordinals from Andrew Schulman’s book, 
Undocumented Windows. 


Q We are an Italian group of Windows developers racking 
our brains on three problems: 

• We must be able to extract all icon resources from an EXE 
or DLL file. 

• what icon is used by Program Manager to display an ap¬ 
plication containing more than one icon? 

• Is the drag-and-drop feature used by Program Manager 
documented in the SDK? 

Marco Russo 

Marco.Russo@p 110.fi .n334.z2.fidonet.org 
Andrea Actis 


Listing 1 continued 

#include <windows.h> 


LPARAM); 


linclude <commdlg.h> 


VOID PaintWnd(HWND); 


linclude <shellapi.h> 


VOID Storelcons(LPSTR); 


linclude <memory.h> 

#include "showicon.h" 


int PASCAL 

WinMain(HINSTANCE hinsThis, HINSTANCE hinsPrev, 


HICON * rgicn; 

// Array of icons. 

LPSTR lszCommand, int wShowWindow) 


int cicn; 

// Count of icons in array. 

/////////////////////////////////////////////////////// 

HINSTANCE hins; 

// Instance of app. 

// - Entry point. 

// 



/////////////////////////////////////////////////////// 

char szFilterf] = 

// File filter list. 

{ 


”Executable(*.exe)\0 

*.exe\0DynaLink(*.dll)\0*.dll\0"; 

MSG msg; 


char szAppf] = 11 

Showlcon"; 

HWND hwnd; 


VOID GetFilelcons(HWND); 

hins * hinsThis; 


LONG CALLBACK MainWndProc(HWND, DINT, WPARAM, 

if (hinsPrev «* NULL) 
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Andrea.Actis@p11 l.fl .n334.z2.fidonet.org 

Teodoro Lio 

Teodoro.Lio@p 10.f 104.n334.z2.fidonet.org 

A Fortunately, Windows 3.1 provides a new function, 
Extract Icon (), that does precisely what you want. 
Given the name of an executable or DLL, the instance of the 
application making the call, and the index of the icon, 
Extract Icon () returns a handle to the icon. If you pass an 
icon index of -1, Extract Icon () returns the number of icons 


in the file. This function is documented in Microsoft’s 
Programmer's Reference, Volume 2, on page 296. 

From empirical study, I believe the Program Manager al¬ 
ways picks the first icon in a . exe or DLL as the default icon 
to display in a group. The user can change this with the 
File/Properties dialog to display any icon in the file. 

Windows 3.1 includes shell.dll, which provides file drag- 
and-drop functionality in the form of four functions. You call 
DragAcceptFiles() to inform Windows whether or not a par¬ 
ticular window can act as a drop target. A window that is a 
drop target will receive the UM_DROPFILES message when a 


Listing 1 continued 


{ 

case WM COMMAND: 

WNDCLASS wcs; 

if TwParam != idmFileOpen) 
return 

wcs.style = CS HREDRAW | CS VREDRAW; 

DefWindowProc(hwnd, wm, wParam, IParam); 

wcs.lpfnWndProc * MainWndProc; 


wcs.cbClsExtra ■ 0; 

GetFilelcons(hwnd) ; 

wcs.cbWndExtra ■ 0; 

break; 

wcs.hlnstance = hins; 


wcs.hlcon = NULL; 

case WM DESTROY: 

wcs.hCursor = LoadCursor(NULL, IOC ARROW); 

if (rgicn != NULL) 

wcs.hbrBackground = (HBRUSH)(COLOR WINDOW + 1); 

Local Free((HLOCAL)rgicn) ; 

wcs.lpszMenuName * szApp; 

PostQuitMessage(O); 

wcs.lpszClassName = szApp; 

break; 

if (! Register'd ass (&wcs)) 


return FALSE; 

case WM PAINT: 

} 

PaintWnd(hwnd); 
break; 

if ((hwnd « CreateWindow( 

} 

szApp, 


"Show Icons", 

return 0; 

WS OVERLAPPEDWINDOW, 

) 

CW USEOEFAULT, 


wShowWindow, 

VOID 

CW USEDEFAULT, 

StoreIcons(LPSTR lszFile) 

CW USEDEFAULT, 

/////////////////////////////////////////////////////// 

NULL, 

// - Grab the icons from the given file. // 

NULL, 

// - lszFile : File containing icons. // 

hins, 

lllllllllllllllllllllllllllllllllllllllllllllllllllllll 

NULL)) == NULL) 

{ 

return FALSE; 

int icn; 

ShowWindow(hwnd, wShowWindow); 

if (rgicn !■ NULL) 

UpdateWindow(hwnd) ; 

( 

Local Free ( (HLOCAL)rgicn) ; 

while (GetMessage(&msg, NULL, NULL, NULL)) 

rgicn = NULL; 

{ 

cicn « 0; 

TranslateMessage(&msg) ; 

} 

DispatchMessage(&msg) ; 


) 

cicn = (int)Extractlcon(hins, lszFile, (UINT)-1) ; 
if ((rgicn = (HICON *)LocalAlloc(LPTR, 

return msg.wParam; 

cicn * sizeof(HICON))) == NULL) 

) 

return; 

LRESULT CALLBACK 

for (icn » 0; icn < cicn; icn++) 

MainWndProc(HWND hwnd, UINT wm, WPARAM wParam, 

rgicnficn] = ExtractIcon(hins, lszFile, icn); 

LPARAM IParam) 

) 

/////////////////////////////////////////////////////// 


// - Main window procedure. // 

VOID 

/////////////////////////////////////////////////////// 

PaintWnd(HWND hwnd) 

{ 

/////////////////////////////////////////////////////// 

switch (wm) 

// - Paint the icons in the main window. // 

{ 

// - hwnd : Window to paint in. // 

default: 

/////////////////////////////////////////////////////// 

return DefWindowProc(hwnd, wm, wParam, IParam); 

{ 

PAINTSTRUCT wps; 
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user drops one or more files on the window. You call Drag- 
QueryFile() upon receipt of UM_DROPFILES to determine the 
number of files dropped and their names. You can also call 
DrawQueryPoint() upon receiving a UM_DROPFILES message to 
get the coordinates of the mouse pointer when the files were 
dropped. DragFinishf) should be called at the end of 
processing a UM_DROPFILES message. 

Windows 3.0 did not document the drag-and-drop func¬ 
tions, and Windows 3.1 only documents how to write a drag- 
and-drop client (that is, Microsoft does not reveal how File 
Manager acts as a server, initiating the dragging of files). How¬ 
ever, an article by Jeffrey Richter in the May-June issue of 
Microsoft Systems Journal (vol. 7, no. 3: p. 19) describes how to 
implement a drag-and-drop client and a server (using undocu¬ 


mented functionality). Further information can be obtained 
from the SDK's Programmer's Reference, Volume 1, on page 
266, and in the SDK's Programmer's Reference, Volume 2, 
pages 242 to 245. Also, Schulman's Undocumented Windows 
explains how this functionality is implemented in both ver¬ 
sions 3.0 and 3.1. 

I present a small demo program, Showlcon, in Listing 1 
through Listing 5 (C source file, header file, resource file, linker 
module definition file, and makefile, respectively). The program 
uses the file open dialog from the new common dialog library 
to specify a file to extract icons from. Showlcon then displays 
the icons in the client area. To see lots of icons, take a look at 
the file moricons.dll, in your Windows directory! 


Listing 1 continued 


int icn; 

RECT rect; 

int x 0; 

int y =0; 

int dx = GetSystemMetrics(SM_CXICON); 

int dy = GetSystemMetrics(SM_CYICON); 

GetClientRect(hwnd, &rect); 

BeginPaint(hwnd, &wps); 

for (icn = 0; icn < cicn; icn++) 

{ 

if (rect.right - x < dx) 

{ 

x ■ 0; 
y +■ dy; 

) 

if (rect.bottom - y > dy) 

( 

Drawlcon(wps.hdc, x, y, rgicnficn]); 
x += dx; 

) 

} 

EndPaint(hwnd, &wps); 

} 


VOID 

GetFileIcons(HWND hwnd) 

/////////////////////////////////////////////////////// 

// - Extract the icons from the given file. // 

// - hwnd : Window to display icons. // 

/////////////////////////////////////////////////////// 
{ 

0PENFILENAME ofn; 

char szBuf [256], szFile[128], 

szTitle[13]; 

GetWindowsDirectory(szBuf, sizeof szBuf); 

memset(&ofn, 0, sizeof ofn); 
szFilefO] = szTi tl e[0] ■ ' \0'; 
ofn.lStructSize = sizeof ofn; 
ofn.hwndOwner = hwnd; 
ofn.lpstrFilter = szFilter; 
ofn.nFilterlndex » 1L; 
ofn.lpstrFile = szFile; 
ofn.nMaxFile ■ sizeof szFile; 
ofn.lpstrFileTitle « szTitle; 
ofn.nMaxFileTitle = sizeof szTitle; 
ofn.lpstrlnitialDir = szBuf; 

ofn.Flags - 0FN_HIDEREADONLY | 0FN_FILEMUSTEXIST; 


if (GetOpenFileName(&ofn)) 

{ 

HCURS0R hcsrSav; 
hcsrSav = 

SetCursor(LoadCursor(NULL, IDC_WAIT)); 
Storelcons(ofn.lpstrFile); 
SetCursor(hcsrSav); 

InvalidateRect(hwnd, NULL, TRUE); 

} 

} 

/* End of File */ 
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Listing 2 showicon.h - Resource interface to 
Showlcon 


Idefine idmFileOpen 0x1000 // Menu item id. 
/* End of File */ 


Q Being somewhat isolated as a programmer (I'm really a 
biochemist), I am largely self-taught, learning from books 
and magazines. I have three questions that have stymied me 
for months now. 

First, how does Excel rotate bitmapped fonts in the axis 
titles of charts? Both versions 3.0 and 4.0 can rotate supposed¬ 
ly non-rotatable fonts such as “Tms Rmn.” I have no problems 
with stroked fonts like "Modern,” or TrueType fonts in Win¬ 
dows 3.1. However, I want my program to be able to run 
under OS/2.0, which doesn't support TrueType at this time, so 
I am restricted to Windows 3.0 font handling. 

Second, how does Excel draw patterned lines more than 
one pixel thick? Is it something as mundane as drawing one- 
pixel thick lines next to each other or something clever? 

Third, how does the "Print Preview” feature available in so 
many programs work? Is it something like forcing the printer 
driver to output to a display context? Something weirder? 

David C. Clark 
68678 CR 13 
Nappanee, IN 46550 


Listing 3 showicon.rc - Resource file for 
Showlcon 


lindude <windows.h> 

#include "showicon.h" 

Showlcon MENU // Pretty simple menu. 

BEGIN 

POPUP "&File" 

BEGIN 

MENUITEM "File &0pen...\ idmFileOpen 
END 
END 


A I used my trusty old debugger, WDEB386, to investigate 
all of your questions. Excel is written largely in P-code, 
which usually makes it very hard to debug, since you are 
looking at the P-code interpreter as you single-step through 
the code. The interpreter is grabbing P-code operations from 
the various code segments as if they were data, and jumping 
through a lookup table to the piece of code that implements 
that particular P-code instruction. However, when you want to 
see what Windows functions get called, P-code is actually an 
advantage. 

A P-code call will be implemented as just another piece of 
native code. So if you find that piece of code, you can set a 
breakpoint on the CALL instruction that actually calls the Win¬ 
dows function. By necessity, it will be a call through a table of 
pointers to Windows functions. Once you have this break¬ 
point, you can see each function as it is called, and examine 
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Listing 4 showicon.def — Linker definition file for 
Showlcon 

NAME 

Showlcon 


DESCRIPTION 

'Icon Extraction 

Demo 1 

EXETYPE 

WINDOWS 


STUB 

'WINSTUB.EXE' 


CODE 

PRELOAD MOVEABLE 

DISCARDABLE 

DATA 

PRELOAD MOVEABLE 

MULTIPLE 

HEAPSIZE 

1024 


STACKSIZE 

10240 


EXPORTS 



MainWndProc @1 



the parameters to the function. There is a small complication 
to this scheme: the P-code interpreter is optimized for various 
types of P-code calls. There are separate P-code call instruc¬ 
tion variants depending on how many parameters an API 
uses. So, you need to set a breakpoint on each of these 
variants. 

To find the code segment containing these CALLS, you can 
set a breakpoint on a Windows function that is likely to be 
called from the P-code application. I used ExtTextOut() while 
a chart was painting its axes. On entry to ExtTextOut(), I got 
the CS:IP of the caller from the first two words of the stack 
frame (in WDEB386 this can be achieved with "dw ss:sp l 
2"). If you disassemble the segment that is given by CS on the 
stack frame, beginning at offset 0 ("u xxxx:0 "), you will even¬ 
tually see all the various CALLS. Look for statements such as 

CALL DWORD PTR ss:[BX+xxxx] 

In Excel 4.0, these can be found at offsets 0x0286, 0x0399, 
0x04b7, 0x04e7, 0x04ee, 0x04f9, 0x0500, 0x050a, 0x0511, and 
0x053e. I don't make any claim that these are all the CALL 
instructions, nor that all of these are actually used to call Win¬ 
dows functions, but they were sufficient to answer your ques¬ 
tions. 

There is actually one more complication. Excel is not purely 
P-code, but is a mixture of P-code and native code. P-code is 
used to save space in those areas where speed is not critical, 
such as user interface code. But native code is used in speed 
critical areas. This means that you will not be able to trap all 
Windows function calls using this method, since in native code 
they will be called directly. However, the drawing code in 
question was all in P-code. 

Now, to answer your questions. To rotate a bitmapped 
font, Excel creates a screen compatible bitmap and a screen 
compatible memory device context. The bitmap is sized large 
enough to accept the line of text, is selected into the memory 
device context, and ExtTextOutf) is called to write the text 
onto the device context surface, the bitmap. A new bitmap is 
created based on the first, but with the width and height 
values interchanged. The bits of the first are obtained, 
transposed into a new bit array, and set into the new bitmap. 
The new bitmap is selected into the memory device context, 
and bitblitted onto the screen. I wrote a routine to 
demonstrate this: RotBmpO is in Listing 6. RotBmpO uses Get- 
Pixel () and SetPixel() to avoid the problem of pixel repre¬ 
sentation in color bitmaps. A bitmap can be composed of a 
series of multi-bit pixels, or an array of monochrome bitmaps. 


Listing 5 showicon.mak — Makefile for Showlcon 


all: showjoy.exe 

showjoy.obj: showjoy.c 

cl -c -AM -G2w -Od -Zdpe -W3 -DSTRICT showjoy.c 

showjoy.exe: showjoy.obj showjoy.def showjoy.rc \ 
makefile 

link /NOD/m showjoy,,, libw mlibcew, showjoy.def 
rc $ (DEFS) showjoy 

mapsym showjoy 


As long as the bitmap to rotate is compatible with the screen, 
you can create a pair of screen compatible device contexts, 
and let GDI isolate the details for you. The drawback, how¬ 
ever, is that this is very slow. Efficient code will manipulate 
the bits directly, as Excel does. 

Excel actually draws patterned lines as a series of 
Polygon () calls. For example, a thick dashed pen is drawn 
with a filled polygon for each dash. Excel has lots of code for 
drawing lines, since Windows 3.1 doesn't. 

Your last question was the hardest to answer. The printer 
driver is not being asked to perform the drawing. As far as I 
can tell, the printer driver is queried for its physical page size 
and printing offset. Excel then scales and offsets the viewport 
to map the part of the client area used to display the preview 
to the dimensions of a physical page. I guess at this scale that 
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WSYWIG becomes less discernible, making this approach ac¬ 
ceptable. 

Q How can I read the values of the joysticks and buttons 
on the IBM game port under Windows? I am currently 
using Borland C++ V3.0 with the Application Frameworks. 
There seems to be no mention of the IBM game port in the 
Borland documentation. 

Solomon Martinez 
11887 Redband Street 
Sun Valley, CA 91352 

A Well, there is very little mention in the Microsoft 
documentation as well! After much digging, I did locate 
some pages dedicated to joystick support in the MuldMedia 
Programmer’s Reference, under the heading "Joystick Services.” 
The services provided query joystick hardware capabilities, 
query joystick position, capture and release the joystick (this 
permits message-driven input instead of polling), and include a 
pair of routines to query and set the movement threshold. To 
be able to use these services, you need an installable joystick 
driver. Such a driver is not part of the standard Windows in¬ 


stallation. Sample driver code is available with the DDK, and 
you could distribute a joystick driver based on this code with 
your application. Fortunately, there is an alternative solution, 
since IBM BIOS’s created after 10 July 1986 include joystick 
support via interrupt 15h, function 8400h. This interrupt is 
available in both standard and enhanced mode, and is virtual¬ 
ized for enhanced mode VMs. It can be called from a Win¬ 
dows application, so is a more general solution than relying 
on a device driver, when the interrupt is called with DX^OOOO, 
the switch settings are returned in bits 4-7 of AX. Bits 4 and 5 
are for the two switches of joystick 1, and bits 6 and 7 are for 
joystick 2. A 0 bit indicates the switch is closed. When called 
with DX=0001, the resistive values are returned in AX, BX, CX, 
and DX. AX and BX are for joystick 1, and CX and DX for joystick 
2 . 

When called from DOS, the resistive values returned range 
from 0 to 255. But when called from a DOS VM or Windows 
program (i.e., in the system VM) in enhanced mode, the range 
is from 0 to 127. It would seem that this is timing related. A 
resistive value is obtained by reading the joystick port ( 201h) 
in a loop, waiting for a bit to clear once a threshold is reached 
on the game port adapter. A counter records the iterations 


Listing 6 rotbmp.c - Rotate a bitmap 90 degrees counterclockwise 


♦include <windows.h> 

HBITMAP 

RotBmp(HBITMAP hbmpOrig) 

/////////////////////////////////////////////////////// 


// -- Routine to rotate a bitmap. // 
// -- Returns a rotated copy of the original. // 
// -- This routine uses the GetPixelf) and // 
// SetPixel() for illustrative purposes. It // 
// would be more efficient to manipulate the bits // 
// directory. // 
// -- hbmpOrig : Bitmap to rotate. // 


/////////////////////////////////////////////////////// 

( 

BOOL fSuccess * FALSE; 

HBITMAP hbmpNew = NULL; 

HDC hdcScreen = NULL; 

HOC hdcOrig = NULL; 

HDC hdcNew = NULL; 

HBITMAP hbmpOrigSav = NULL; 

HBITMAP hbmpNewSav = NULL; 

BITMAP bmp; 
int x, y; 

// Get size of bitmap. 

if (Get0bject((HGDI0BJ)hbmp0rig, sizeof bmp, &bmp) 
1= sizeof bmp) 
goto RotBmpExit; 

// Get the bitmap for the rotated copy. Note that 
// width and height are switched. 
hbmpNew = CreateBitmap(bmp.bmHeight, bmp.bmWidth, 
bmp.bmPlanes, bmp.bmBitsPixel, NULL); 
if (hbmpNew == NULL) 
goto RotBmpExit; 

// Get memory DC' for the copy. 
hdcScreen = GetDC(NULL); 
if (hdcScreen == NULL) 
goto RotBmpExit; 


if (hdcOrig == NULL) 
goto RotBmpExit; 

hdcNew = CreateCompatibleDC(hdcScreen); 
if (hdcNew == NULL) 
goto RotBmpExit; 

hbmpOrigSav = SelectObject(hdcOrig, hbmpOrig); 
hbmpNewSav ■ SelectObject(hdcNew, hbmpNew); 

// Get original bits, and copy at 90 degrees into 
// new bit array. 

for (y * 0; y < bmp.bmHeight; y++) 
for (x = 0; x < bmp.bmWidth; x++) 

SetPixel(hdcNew, y, bmp.bmWidth - x, 
GetPixel(hdcOrig, x, y)); 

fSuccess = TRUE; 

RotBmpExit: 

if (hbmpNewSav != NULL) 

SelectObject(hdcNew, hbmpNewSav); 
if (hbmpOrigSav 1= NULL) 

SelectObject(hdcOrig, hbmpOrigSav); 
if (hdcNew != NULL) 

DeleteDC(hdcNew); 
if (hdcOrig ! = NULL) 

DeleteDC(hdcOrig); 
if (hdcScreen != NULL) 

ReleaseDC(NULL, hdcScreen); 
if (!fSuccess && hbmpNew 1= NULL) 

{ 

DeleteObject(hbmpNew); 
hbmpNew = NULL; 

} 

return hbmpNew; 

} 

/* End of File */ 


hdcOrig * CreateCompatibleDC(hdcScreen); 
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and is used as the value of the potentiometer. So, any port 
trapping could result in the threshold being reached in fewer 
iterations. This is only a theory, I have not verified it. 

The resistive values are prone to considerable jitter. Some 
sort of smoothing may be appropriate, depending on your 
needs. For example, if you are using the joystick to rotate a 
3-D object that consumes a lot of time, the user probably will 


not notice the jitter. However, if you are performing a quick 
operation like positioning the mouse pointer, the jitter can be 
noticeable. 

Since you will be polling, you could either use a timer to 
trigger the I NT 15h call or make the call from inside a Peek- 
Message () loop, to avoid pausing inside GetMessage(). The first 
solution is the friendliest, since it still allows GetMessage() to 


Listing 7 showjoy.c — Move cursor based on joystick input 


linclude <windows.h> 

#include "showjoy.h" 

Idefine wJoyMax 256 // Max. possible joystick position. 
Idefine cptAvg 5 lit pts to average for smoothing. 
Idefine wRead 0x0001 // Read joystick? 

Idefine wCal 0x0002 // Calibrate joystick? 


int dxClient, dyClient; // Size of client area, 

struct 

( 

int x, y; II Upper left corner, 

int dx, dy; // Width and height. 

} recJoy = 

{ 

wJoyMax, wJoyMax, 0, 0 

}; // Joystick travel limits, 

char szApp [] * “ShowJoy"; 


VOID 

VOID 

LONG CALLBACK 

VOID 

POINT 

UW 


AveragePt(P0INT *); 
CalibrateJoy(HWND); 
MainWndProc(HWND, UINT, WPARAM, 
LPARAM); 
PaintWnd(HWND); 
PtSetCursorPosFromJoy(HWND); 
WGetJoySwitches(VOID); 


int PASCAL 

WinMain(HINSTANCE hinsThis, HINSTANCE hinsPrev, 

LPSTR lszCommand, int wShowWindow) 

lllllllllllllllllllllllllllllllllllllllllllllllllllllll 

II -- Entry point. // 

/////////////////////////////////////////////////////// 
{ 

MSG msg; 

HWND hwnd; 


if (hinsPrev «* NULL) // Register a class? 

( 

WNDCLASS wcs; 


wcs.style = CSHREDRAW | CS_VREDRAW; 
wcs.lpfnWndPrc = MainWndProc; 
wcs.cbClsExtra * 0; 
wcs.cbWndExtra = 0; 
wcs.hlnstance = hinsThis; 
wcs.hlcon = NULL; 

wcs.hCursor = LoadCursor(NULL, IDC_ARR0W); 
wcs.hbrBackground = (HBRUSH)(C0L0R_WIND0W + 1); 
wcs.lpszMenuName ■ szApp; 
wcs.lpszClassName = szApp; 
if (!RegisterClass(&wcs)) 
return FALSE; 

} 


if ((hwnd = CreateWindow(szApp, szApp, 
WS_OVERLAPPEDWIND0W, CW_USEDEFAULT, wShowWindow, 
CWJJSEDEFAULT, CW_USEDEFAULT, NULL, NULL, 
hinsThis, NULL)) == NULL) 
return FALSE; 


ShowWindow(hwnd, wShowWindow); 
UpdateWindow(hwnd); 

for (;;) 

if (GetMessage(&msg, NULL, NULL, NULL)) 

{ 

TranslateMessage(&msg); 
DispatchMessage(8.msg); 

} 

return msg.wParam; 

) 





80386 USEI6 80387 

USE32 80486 


LRESULT CALLBACK 

MainWndProc(HWND hwnd, UINT wm, WPARAM wParam, 

LPARAM 1 Param) 

/////////////////////////////////////////////////////// 

// — Main window procedure. // 

/////////////////////////////////////////////////////// 

( 

static UINT wPollJoy; // Poll joystick? 
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Listing 7 continued 


switch (wm) 

/////////////////////////////////////////////////////// 

// — Return the joystick switch settings. // 

{ 

/////////////////////////////////////////////////////// 

default: 

( 

return DefWindowProc(hwnd, wm, wParam, IParam); 

asm 

/ 

case WM TIMER: 

i 

mov ax, 0x8400 

if (WGetJoySwitchesO) // Do something? 

mov dx, 0x0000 

{ 

int 0x15 

if (wPollJoy & wRead) 

shr ax, 4 

PtSetCursorPosFromJoy(hwnd); 

not ax 

else if (wPollJoy & wCal) 

and ax, OxOOOf 

CalibrateJoy(hwnd); 

} 

break; 

case WM INITMENUPOPUP: // Set or clear checkmark. 

) 

\ 

l 

POINT 

PtSetCursorPosFromJoy(HWND hwnd) 

if (HIWORD(lParam) == 0 && L0W0RD(1Param) == 0) 

/////////////////////////////////////////////////////// 

{ 

// -- Position the cursor on the screen based on the // 

CheckMenuItem((HMENU)wParam, 

// position of the joystick. // 

idmReadJoyStick, (wPollJoy & wRead) ? 

// -- Return the joystick position. // 

MF CHECKED : MF UNCHECKED); 

// -- hwnd : Window to move cursor in. // 

CheckMenuItem((HMENU)wParam, 

lllllllllllllllllllllllllllllllllllllllllllllllllllllll 

idmCalibrateJoy, (wPol 1 Joy & wCal ) ? 

( 

MF CHECKED : MF UNCHECKED); 

) 

break; 

POINT ptVal ; 

asm mov ax, 0x8400; 

case WM COMMAND: 

_asm mov dx, 0x0001; 

asm int 0x15; 

switch (wParam) 

asm and ax, OxOOff; 

{ 

asm and dx, OxOOff; 

default: 

asm mov ptVal.x, ax; 

return 

asm mov ptVal .y, bx; 

DefWindowProc(hwnd, wm, wParam, IParam); 


case idmReadJoyStick: 

if (recJoy.dx != 0 && recJoy.dy != 0) 

{ 

wPollJoy A = wRead; // Toggle read bit. 

POINT pt; 

break; 

long lx, ly; 

case idmCalibrateJoy: 

lx = ptVal.x - recJoy.x; 

wPollJoy A = wCal ; // Toggle calibrate bit. 

lx *= dxClient; 

if (wPollJoy & wCal) 

lx /= recJoy.dx; 

{ 

pt.x = (int)lx; 

recJoy.x = recJoy.y = wJoyMax; 

ly = ptVal.y - recJoy.y; 

recJoy.dx * recJoy.dy = 0; 

ly *- dyClient; 

) 

ly /= recJoy.dy; 

break; 

pt.y = (int)ly; 

) 

AveragePt(&pt); 

if (wPollJoy) 

ClientToScreen(hwnd, &pt); 

SetCursorPos(pt.x, pt.y); 

SetTimer(hwnd, 1, 30, NULL); 

) 

else 

KillTimer(hwnd, 1); 

return ptVal; 

break; 

) 

case WM DESTROY: 

VOID 

PostQuitMessage(O); 

CalibrateJoy(HWND hwnd) 

KillTimer(hwnd, 1); 

/////////////////////////////////////////////////////// 

break; 

// -- Determine the extents of joystick travel. // 

case WM SIZE: 

// -- hwnd : Window to move cursor in. // 

/////////////////////////////////////////////////////// 

dxClient = L0W0RD(1Param); 

{ 

dyClient = HIW0RD(1Param); 

POINT pt; 

break; 

} 

pt = PtSetCursorPosFromJoy(hwnd); 

return 0; 

if (pt.x < recJoy.x) 
recJoy.x = pt.x; 

} 

if (pt.y < recJoy.y) 

UW 

recJoy.y = pt.y; 

if (pt.x > recJoy.x + recJoy.dx) 

WGetJoySwitches(VOID) 

recJoy.dx = pt.x - recJoy.x; 
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Listing 7 continued 


if (pt.y > recJoy.y + recJoy.dy) 
recJoy.dy * pt.y - recJoy.y; 

) 

VOID 

AveragePt(POINT * ppt) 

/////////////////////////////////////////////////////// 
// — Average the last 5 positions for smoothing. // 

// — ppt : On input, new data point. // 

// On output, smoothed point. // 

/////////////////////////////////////////////////////// 
( 


static 

POINT 

rgpt [cptAvg]; 

// Previous points. 

static 

int 

cpt; 

// # total points. 


int 

ipt; 

// Array index. 


int 

cptUse; 

// # pts in array. 


rgpt[cpt++ % cptAvg] ■ *ppt; // Store point. 
ppt->x * ppt->y * 0; 

cptlise = min(cpt, cptAvg); // Don't average nulls, 
for (ipt * 0; ipt < cptUse; ipt++) 

( 

ppt->x +* rgpt[ipt].x; 

PPt->y +- rgpt[ipt].y; 

) 

ppt->x /■ cptUse; 
ppt->y /= cptUse; 

) 

/* End of File */ 


yield control. If your application is run¬ 
ning on a laptop, it must yield when no 
messages are in its queue so as to 
allow Microsoft's (battery) power 
management strategy to function. 
Those applications that use a Peek- 
Message ()-based pump and that do not 
call UaitMessagef) will be considered 
ill-behaved. 

Listings 7 through 11 implement a 
demo application that positions the cur¬ 
sor based on the joystick's resistive 
values. It implements the “well-be¬ 
haved” method of using a timer to trig¬ 
ger polling and features a "calibrate" 
menu item which when checked will 
record the extreme values obtained. 
The idea is to pick “calibrate,’’ then 
move the joystick along its four outer¬ 
most edges. The result is a "rectangle” 
of positions that can then be mapped 
to screen coordinates when the "read" 
menu item is checked. If either "read” 
or “calibrate” are checked, the joystick 
switches are read and if either of them 
is closed, the appropriate call is made 
to either position the cursor or calibrate 
the joystick. A timer is then installed 
with a period of 33 milliseconds. I chose 
33, since in ideal conditions this would 
cause a refresh rate of about 30Hz, 
which is just tolerable without being 
too piggish. 

UGetJoySwi tches () is really a tiny 
assembly language routine (in the guise 
of a C function) that makes the I NT 15h 
call with DX=0000, shifts AX four bits to 
the right to get bits 5 and 6 into the 
least significant positions, and ANDs the 
result with 0x0003 to ensure that only 
joystick 1 is being reported. The value 
left in AX at the end of the assembler 
block will become the return value of 
the function (C return convention). 


How to build industrial strength 
database applications under Windows 


Quadbase-SQIVWin™ 

is the SQL engine of choice for 
developing applications under Win¬ 
dows using your favorite front- 
end/language such as Visual Basic, C, 
C + +, ObjectView, Toolbook, 
SQLWindows etc.. Whether your ap¬ 
plication runs on Laptops, Pen-based 
systems or LANs, you will fmd that 
Quadbase-SQL/Win sets price/per¬ 
formance standards. 

Quadbase-SQL/Win™, a DLL, is a 
full-featured relational database en¬ 
gine which is very fast, compact and 
specially designed to main age large 
amounts of data efficiently. 

The underlying file formats are 
dBASE compatible. It can also read 
Lotus 1-2-3 files and index files from 
Clipper, FoxPro and dBASE IV. 

Find out why GE, Compaq Computer, 
Microsoft, ABB, The Upjohn Co., 
AT&T and many more top notch com¬ 
panies are using Quadbase-SQL/Win. 

dQUERY is your award-win¬ 
ning power tool for ad hoc 
querying, report writing, and 
building canned query systems 
using SQL and QBE. 



• Fully supports ANSI SQL 86 level 2 
standards, outer-join, referential 
integrity constraints, multi-user 
concurrency controls (four isola¬ 
tion levels), crash recovery, transac¬ 
tion processing, scroll cursors and 
security features. 

•Supports multiple instances, BLOB 
and read-only schemas (for CD- 
ROMs). 

• Offers custom controls for Visual 
Basic. 

• supports embedded SQL for Visual 
Basic and other languages. 

• Embedded SQL preprocessor for 
C. 

• VBQUERY, an interactive query 
tool, written in Visual Basic and 
dQUERY are included. 

Call for a free demo disk. 

Quadbase 
Systems Inc. 

790 Lucerne Drive #51 
Sunnyvale, CA 94086 
Voice: (408) 738-6989 
Fax: (408) 738-6980 



* Other trademarks appearing in this ad are trademarks of their respective companies. 
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Listing 8 showjoy.h — Resource interface to 
ShowJoy 


Idefine idmReadJoyStick 0x1000 
Idefine idmCalibrateJoy 0x1001 


Listing 9 showjoy.rc — Resource file for ShowJoy 


linclude <windows.h> 
linclude "showjoy.h" 

ShowJoy MENU // Pretty simple menu. 

BEGIN 

POPUP "&Joystick" 

BEGIN 

MENUITEM "&Read", idmReadJoyStick 

MENUITEM “&Calibrate", idmCalibrateJoy 

END 
END 


PtSetCursorPosFromJoyO gets the resistive values, and if 
the current width and height of the joystick travel limits are 
non-zero, positions the cursor. It calls AveragePtf), which im¬ 
plements smoothing. AveragePtf) keeps an array of the last 
five positions and returns their average. This results in a 
somewhat mushy response, so you might want to allow the 
user to specify the size of the array (instead of using the con¬ 
stant cptAvg). CalibrateJoyf) records the limits of travel. It 
calls PtSetCursorPosFromJoyO , which will return the joystick 


Listing 10 showjoy.def - Linker definition file for 
Showjoy 

NAME 

ShowJoy 

DESCRIPTION 

'Joystick Demo 1 

EXETYPE 

WINDOWS 

STUB 

■WINSTUB.EXE' 

CODE 

PRELOAD MOVEABLE DISCARDABLE 

DATA 

PRELOAD MOVEABLE MULTIPLE 

HEAPSIZE 

1024 

STACKSIZE 

10240 

EXPORTS 


MainWndProc @1 


Listing 11 showjoy.mak — Makefile for ShowJoy 


all: showjoy.exe 

showjoy.obj: showjoy.c 

cl -c -AM -G2w -Od -Zdpe -W3 -DSTRICT showjoy.c 

showjoy.exe: showjoy.obj showjoy.def showjoy.rc \ 
makefile 

link /N0D/m showjoy,,, libw mlibcew, showjoy.def 
rc $(DEFS) showjoy 
mapsym showjoy 


position, even if it does not update the cursor position. If the 
point lies outside the current travel rectangle, the rectangle's 
size is increased. □ 


SuperSound 
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Digital Audio Authoring 
Workstations/ 
Tools, >100 KHz 
SamplingRate 


ULIIKU . 
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tm 

{? ~wmm 1 
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i Stereo / Mono Hardware and 
Software Kits - only $254 / $179 


GUI Editors $19 to $149 

Developers for Windows 3.0 / DOS 
Create Sounds for SoundBlaster, Covox, 
Disney; Import Mac, Amiga Sounds... 

DLLs, C, Turbo C, C + +, Visual Basic, Quick Basic Tools 
Data Compression / Decompression of 8:6, 8:4, 8:2, 8:1... 

IBM-PC DIGITAL VOICE / SOUND 
from only $20 


User’s Player Module 
Printer Port Audio D/A 


O Developer’s 

- -4*0HW/SWKits 


Pro Quality Software / Hardware 
- in use worldwide, even Japan! 

30 Day Money-Back Guarantee if not Satisfied 

. JUST LIKE HAVING A CASSETTE TAPE RECORDER IN A PC. 

> Fastest, easiest Editors with the most features for the price. 

> Quick, simple hardware / software installation. 

» Use for Foreign Language training / communications, 
i For Business: Training, Slide Shows - with Grasp, ShowPartner F/X, and others. 

» For Engineering: Function Generators, Clear Voice Alarms, Storage Scope... 

> Complete Technical Support: Help on Digital Audio HW/SW - no extra charge. 

by Silicon Shack Ph:408-446-4521 FAX: 408-446-5196 _ 

4760 Castlewood Drive, San Jose, CA 95129. 

Technical Info./Orders: 800-969-4411 

Ask for FREE PRODUCT CATALOG. 

In Far East: Bayware Japan, Inc. Tel:(03)972-5391 FAX: (03)959-1214 

OEM Developers: Add QUALITY audio hardware to your product 

SuperSound. SoundFX, SoundCard are trademarks of Silicon Shuck, Ltd. Other product names are trademarks of their manufacturers. 
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DISASSEMBLERS ■■ 

Recover your source code from compiled 
applications with the following programs: 


Valkyrie, by Code Works, for Clipper S '87. 

$345.00 

OutFoxPro for unencrypted FoxPro 1.x. . . 

.$149.95 

OutFoxPro2 for unencrypted FoxPro 2..... 

$149.95 

OutFOX for unencrypted FoxBASE-t-. 

$149.95 

UEFOX+ unencrypts encrypted FoxBASE+. 

.$395.00 

deFOX for the early FoxBASE II. 

$149.95 

dCRYPTR for AT dBASE m+ RunTime+ 

$149.95 

DECODE for AT dBASE II RunTime. 

$149.95 


HILC O Software 


11266 Barnett Valley Road 
Sebastopol, CA 95472-9255 


Monday thru Friday 


( 707 ) 829-5011 


8 am to 5 pm Pacific 


Add $540 shipping and handling for each order. 

Overseas airmail add $5 j 00 for each program ordered. 
California residents add 7.5% sales tax. VISA & Mastercard accepted. 
PO from government agencies and D&B I or 2. 
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A Drag-and-Drop Custom 
Edit Control 

Part 1 

Ron Burk 


When Windows 3.1 arrived, it became apparent that remarkably little had 
changed in the Windows standard controls (buttons, edit boxes, list boxes, and so 
on). With Windows almost standing still in the user interface arena, applications 
were forging ahead with their own extensions of and replacements for the standard 
controls, with three-dimensional looks, toolbars, status lines, and more. In fact, these 
days a Windows application that uses only the standard Windows controls looks 
quite stodgy and behind the times. 

One of the new interface offerings came in Microsoft's own Word for Windows 
v2.0 (W4W). W4W offers a new drag-and-drop substitute for using the clipboard to 
cut and paste text. With the new interface, you can select some text, grab it with 
the mouse, drag it, and drop it elsewhere in your document. For a quick cut-and- 
paste, this feature is significantly easier to use than the clipboard; unfortunately, the 
Windows 3.1 standard edit control does not offer it 

In this two-part article, I show you how to subclass the standard edit control to 
create dndedit, a new custom control that contains built-in drag-and-drop text sup¬ 
port. The programmatic interface to this new custom control is exactly the same as 
for the standard edit control, so you can plug the improved control in anywhere you 
are currently using a standard multiline edit control. Even if you have no use for a 
drag-and-drop edit control, you may find the implementation issues involved in sub¬ 
classing the standard edit control relevant to other purposes. 


Ron Burk has a B.S.E. E. from the University of Kansas and has been a programmer for 
the past 10 years. You may contact him at Burk Labs, P.O. Box 3082, Redmond, WA 
98073-3082. CIS: 70302,2566. BIX: rlburk; Internet: ronb@rdpub.com (". . . 

luunetlrdpublronb") 
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. cross compilers 
. function libraries 
. tutorials 
. games 
. disassemblers 
. communications 
. compilers 
. languages 
. and more 



CUG 
Library 
Directory 
Volume III 


(Volumes 250-300) 



• volume cross 


reference by topic 
• keyword index 


EXPANDED 


• reviews of key 
volumes 

• capsule summaries 
of all volumes 


The complete reference 
to volumes 250-300 of 
the CUG public domain 
and shareware 
C source code library 


Call 

TODAY! 


913 - 841-1631 
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I take a unique approach to the 
code in this article by presenting some 
functions in C and some in Pascal. In 
fact, I used Turbo Pascal for Windows 
(TPW) as my development environment 
while creating and testing the drag-and- 
drop edit control (in the form of a TPW 
object). When most of the work was 
done, I translated the code into C and 
made it a custom control in a DLL. As is 
the case with most complete custom 
controls, the amount of code required 
for dndedit is too large to fit comfor¬ 
tably into a magazine article. I therefore 
present most of the important parts of 
the code in the accompanying listings 
and will distribute the complete source 
code for both C and TPW as widely as 
possible via our code disk, bulletin 
boards, the Internet, and BIX. 

The Drag-and-Drop Interface 

The place to begin designing a cus¬ 
tom control is with a definition of its 
behavior. In practice, there really is no 
user interface standard for Windows, so 
I decided to make dndedit behave as 
much like Word for Windows as pos¬ 
sible, since that product has been field- 
tested by a great many end users. Al¬ 
though the drag-and-drop interface is 
fairly intuitive to use, the code that im¬ 
plements it has to attend to a fair num¬ 
ber of details, which I enumerate in this 
section. Fortunately, the drag-and-drop 
edit control is mostly a superset of the 
standard edit control, so I will only 
describe the differences in behavior. 


First, the mouse in the dndedit win¬ 
dow changes shape when you place it 
over selected text (selected text is high¬ 
lighted with reverse video by the stand¬ 
ard edit control). This gives the user a 
visual indication that the mouse can 
grab the text. Implementing this feature 
requires that you precisely calculate the 
rectangle that encloses the selected 
text, which can be a bit complicated 
because of proportional fonts. In fact, if 
you type a row of m's into Word for 
Windows v2.0, select a few of them, 
then move the mouse near the left and 
right edges, you will see that Word for 
Windows fails to calculate the enclosing 
rectangle correctly. I chose not to emu¬ 
late that bug in dndeditl 

It is worth noting that you can 
change the text selection (and hence 
the size and position of the enclosing 
rectangle) in any edit control in a 
variety of ways. You can double-click 
the mouse to select the nearest word. 
You can press the left mouse button 
and drag the mouse to select text. You 
can hold the shift key down and press 
any of the position keys (arrows, PgUp, 
and so on) to select text or extend the 
currently selected text, dndedit has to 
be aware of all these events and recal¬ 
culate the enclosing rectangle for the 
selected text appropriately. 

Second, once you place the mouse 
over selected text, pressing the left 
mouse button changes the mouse cur¬ 
sor to a third shape, to indicate that 
you are now dragging the selected text. 
Also, in this state, the text caret moves 


Figure 1 Virtual coordinate view of dndedit 


Virtual text space 


Edit control window 


TextRect 
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with the mouse, indicating the precise 
character position where the text will 
appear if you “drop” the text by releas¬ 
ing the mouse button. While the mouse 
cursor can move to any pixel position in 
the dndedit window, the text cursor 
must move vertically only by whole 
lines and horizontally by whole charac¬ 
ter positions (talcing into account again 
the complication of proportional fonts). 

The dragging state involves some 
more visual details. The text caret has a 
different appearance than the normal 
text caret. The text caret has to appear 
in a reasonable character position, even 
when you move the mouse cursor 
completely outside the edit control win¬ 
dow. Also, if you move the cursor out¬ 
side the edit control window client 
area, the window has to scroll in that 
direction so that you can drag the text 
to areas that are not currently visible in 
the edit control window. Scrolling also 
introduces some other behavioral 
decisions that I will discuss later while 
discussing the code. In the grabbed 
state, the edit control ignores (discards) 
any other characters you might type (or 
mouse buttons you click) while you 
have the left mouse button down. 


Third, the edit control allows the 
user to choose between moving the 
“grabbed” text (deleting it from its 
original position) or copying the 
“grabbed” text (leaving a copy in its 
original position). Normally, dndedit 
moves the text, but, if the control key 
is down at any time during the move, 
dndedit performs a copy instead of a 
move. The user can hold the control 
key down when grabbing the text, or 
press and release the control key one 
or more times while dragging the text, 
or press the control key while dragging 
and release it only after dropping the 
text —so long as the control was in the 
down position at some point while the 
text was being dragged, dndedit per¬ 
forms a copy instead of a move. 

Finally, if you are in the "grabbed" 
state and you release the left mouse 
button, the selected text has to be 
deleted from its original position (unless 
this is a copy operation) and inserted in 
the position indicated by the alternate 
form of the text caret, while remaining 
selected (highlighted). More details arise 
here. If you try to drop the text 
anywhere within the originally selected 
text, the text does not move, although, 
oddly enough, it becomes deselected. 


TM 
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“All of the C language routines 
you need to write an impressive 
scientific graphing program of 
your own. Highly Recommended." 

— PC Magazine 3/14/89 

“Offers a wealth of graphics 
wizardry in its library.” 

— PC Week 8/5/91 



Timpani vibration mode J 21 cos(20) 

New Version! 

"♦Color PostScript® and image 
EPS support 

'••Export HPGL/2, GEM, PIC, 
TIFF, & Tektronix 4105 files 

•TIGA, DGIS and 8514 support 
•Simultaneous plots 
• Color separations 

Licensed for personal use only 
$465 

‘286 extender version $495 

Scientific Endeavors 

508 N. Kentucky Street 
Kingston, TN 37763 
(615) 376-4146 
FAX: (615) 376-1571 
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Figure 2 

Instance data for dndedit 


typedef struct 
/ 

L0NGP0INT 




l 

long X, 

Y; 




} L0NGP0INT; 




typedef struct 
/ 

L0NGRECT 




long Left, Top, Right, Bottom; 


} L0NGRECT; 




typedef struct 
/ 

DNDEDIT 




i 

BOOL 

Grabbed; 

/* 

TRUE if in grabbed state, else FALSE 

*/ 

B00L 

CopyOnly; 

/* 

TRUE if performing copy, not move 

*/ 

int 

SelectionStart; 

/* 

character pos of start of selection 

*/ 

int 

SelectionEnd; 

/* 

character pos of end of selection 

*/ 

int 

InsertionPos; 

/* 

char pos we will "drop" text at 

*/ 

WORD 

CaretBlinkTime; 

/* 

so we can restore correct blink speed*/ 

int 

FontHeight; 

/* 

height of current font — line height*/ 

int 

FontWidth; 

/* 

width of current font — char scroll 

*/ 

long 

Drag; 

/* 

time tick of previous drag scroll 

*/ 

int 

DragAccelerate; 

/* 

interval between drag scrolls 

*/ 

long 

VScrol1; 

/* 

vert offset in device coordinates 

*/ 

long 

HScrol1; 

/* 

horiz offset in device coordinates 

*/ 

int 

HDrag, VDrag; 

/* 

drag scroll direction, 0 if no scroll 

*/ 

long 

ScrollCorrection; 

/* hack for horizontal "jump" 

*/ 

L0NGRECT 

SelRects[3]; 

/* 

rectangles containing selected text 

*/ 

RECT 

TextRect; 

/* 

encloses text area of edit window 

*/ 

HCURS0R 

Cursor; 

/* 

current cursor for WM SETCURS0R 

*/ 

} DNDEDIT; 
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Word for Windows does exhibit one somewhat gratuitous 
incompatibility with the standard edit control. The standard 
edit control always positions the text caret at the ending posi¬ 
tion of selected text. Word for Windows, on the other hand, 
hides the text caret whenever you select one or more charac¬ 
ters. I chose to emulate Word for Windows by hiding the text 
caret, since this feature can easily be disabled if you do not 
care for it, but would be difficult to add later if I did not supp¬ 
ly it. 

Subclass or Start Over? 

The first decision in building this drag-and-drop control was 
whether to start from scratch or subclass the standard edit 
control. The standard edit control's programmatic interface is 


Setting Mouse Cursors 

Setting the mouse cursor is one part of the Windows 
API that nearly every Windows programmer stumbles 
over the first time. After all, given the Windows function 
SetCursor(), it seems obvious that all you have to do is 
call that function when you want to switch to a new 
mouse cursor, right? Wrong. 

In the Windows way of things, the mouse cursor 
shape is not something that stays in place until an ap¬ 
plication decides to change it. Rather, Windows wants 
someone to explicitly choose the shape of the mouse cur¬ 
sor each and every time the mouse moves to a new 
position. When Windows wants your program to make 
that decision, it sends a UM_SETCURSOR to the window 
that contains the new mouse position. If you simply call 
SetCursor(), but pass UM_SETCURSOR messages on to 
DefWndProc(), Windows will reset the cursor shape the 
very next time you move the mouse — a very irritating 
phenomenon when you first encounter it. 

I follow a particular set of steps for every window that 
needs to manage the shape of the mouse cursor. At star¬ 
tup, I call LoadCursor() to obtain handles for all the 
mouse cursors I need. These handles can reside in static 
data, since they are the same for all instances of the win¬ 
dow. In the data structure I associate with each window, I 
reserve space for the handle of the current cursor and 
initialize it to zero. The code for handling m_SETCURSOR 
then looks like this: 

procedure TDndEdit.WMSetCursor 
(var MessageiTMessage); 
begin 

if Cursor <> 0 then 

SetCursor(Cursor) 
el se 

DefWndProc(Message); 
end; 

Then, whenever my code decides to change the mouse 
cursor, it both sets the variable Cursor (which must not 
be static or global data) to the desired cursor handle and 
calls SetCursorf). o 


fairly friendly towards text extensions (such as verifying that 
the text is in a particular format, or customized word wrap¬ 
ping), but it is quite hostile towards visual extensions. It 
provides very little information about or control over how it 
displays the text, the text caret, or the mouse cursor — 
functionality that is crucial for adding the drag-and-drop fea¬ 
ture. 

That sounds like a vote for starting from scratch, but 
duplicating the standard edit control is not a trivial undertak¬ 
ing. Besides handling all the normal window messages, the 
standard edit control responds to 30 custom messages and 
sends 8 custom notification messages. It handles different 
types of scrolling, different types of justification and fonts, the 
clipboard, single- and multi-line controls, and a variety of 
other details, large and small. If you want a control that can 
substitute for the standard edit control in existing applications, 
you have to precisely duplicate all of this functionality. 

Taking all this into account, I gave up on writing my own 
edit control for this project and turned instead to subclassing, 
placing my own window function in place of the standard edit 
control's window function. Since the standard edit control is 
hostile to visual extensions, its visual behavior is poorly docu¬ 
mented, so I regretfully had to depend on undocumented fea¬ 
tures. However, the payoff is that the drag-and-drop edit con¬ 
trol is only hundreds of lines of code instead of thousands, 
and the result is highly compatible with the standard edit 
control. 

Coordinate Systems 

One design decision that requires explanation if you are to 
make sense of the code is my choice of coordinate systems. 
Most code that subclasses the standard edit control operates 
in terms of character positions. For example, if you want to 
subclass an edit control in order to make it accept the same 
control keys as your favorite DOS editor, all you really care 
about is the character offset of the cursor in the text, not the 
position of the text on the screen, dndedit, however, has to 
worry about exactly where characters are within the edit con¬ 
trol window, in terms of client coordinates rather than charac¬ 
ter positions. 

An example will help make this clear. Suppose you select a 
character of text in the middle of a line. Now, if you move the 
mouse over that selection, dndedit has to change the shape 
of the mouse cursor to indicate that you can grab that text 
and drag it elsewhere. That means dndedit must know the 
exact client coordinates of the rectangle that encloses that 
selection, dndedit must also take into account that the stand¬ 
ard edit control draws its text inside a formatting rectangle 
that is usually a bit smaller than the window itself (you can 
obtain this rectangle with an EM_GETRECT message). 

Consider just one part of the necessary calculations. To lo¬ 
cate the left edge of the rectangle enclosing the first line of 
selected text, dndedit can use GetTextExtent() to obtain the 
widths of the characters preceding the first selected character 
on the line —this produces the horizontal position. To find the 
top edge of this rectangle, dndedit can multiply the height of 
each line by the line number of the first selected line. So far, 
so good — but what about scrolling? If the user had scrolled 
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Figure 3 Bounding rectangles for selected text 
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the text vertically or horizontally before selecting the text, 
that throws the calculations off. 

I struggled with these calculations for several hours, never 
quite getting all the calculations correct. Part of my problems 
came from the fact that an int can only hold positive coor¬ 
dinates up to 32,767. Although the edit control window (on 
most video displays) could never exceed that width, some of 
my calculations could. For example, although the displayed 
portion of a line might be small, the portion of text scrolled off 
to the left (which dndedit has to calculate) might have a 
width larger than 32,767. Trying to switch back and forth be¬ 
tween ints and longs at all the right places during calcula¬ 
tions became more trouble than it was worth. 

To solve this problem, I changed my perspective. Rather 
than view the edit control as scrolling the text, I decided to 
view the text as stationary and the edit control as moving 
over the text. By using this model and using longs for my 
virtual coordinate system, I was able to greatly simplify the 
code and get the calculations working correctly in short order. 
Figure 1 shows the conceptual model that I use for coor¬ 
dinates. Whenever dndedit has to perform pixel calculations, 
it prepares two virtual coordinates: VScroll and HScroll. 
These are offsets that indicate how far the window has 
moved vertically and horizontally across the virtual text space. 
Translating from my private virtual coordinates to control win¬ 
dow client coordinates is as simple as subtracting VScroll 
and HScroll and then converting to integers. 

Subclassing a Control 

Subclassing a window (an edit control is just another win¬ 
dow, after all) is a fancy phrase for a simple concept. DOS 
programmers are used to the idea of hooking interrupts. For 
example, if you wanted to write a TSR that prevented anyone 
from deleting your autoexec.bat file, you would “hook” the 
INT 21 h interrupt by first saving the current INT 21h handler, 
then pointing that entry in the interrupt table to your own 
function. Your own handler would then monitor all the INT 
21h requests, passing them on to the previous INT 21h hand¬ 
ler unless it was a request to delete autoexec.bat. 

Window subclassing is entirely analogous to interrupt 
hooking. The function pointer you need to replace lies not in 
the interrupt vector, but in the internal Windows data struc¬ 


ture associated with the window's handle. Rather than call 
getvect() to fetch the previous window message handler 
and setvect() to install your own handler, you can call: 

01dFunc=SetWindowLong(hwnd, 

GWL_WNDPROC, NewFunc); 

Turbo Pascal for Windows (TPW) makes it even easier — all 
you have to do is derive a new class from an existing window 
class, such as TEdit (TPW’s edit control class). In the TPW ver¬ 
sion of dndedit, I let Borland's Object Windows Library (OWL) 
handle all the details —I simply derive a TDndEdit object from 


C/C++ Windows 3.X 

spreadsheet-like ObjectTable 



Multi-column table, horizontal and vertical scroll, 
more than 64 K data, cut and paste to clipboard, 
data validation, easy port to windows C++ library, 
supports Borland OWL and Microsoft MFC 


C object code $79, source code $199 
C++ object code $99, source code $259 

GUI Computer Inc. 1-800-800-9010 

214-250-3472 FAX 214-250-1355 BBS 214-250-2077 

P.O. Box 79S908 Dallas, Texas 75379 
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the standard TEdit object. All the extra data dndedit needs 
to keep track of what it is doing simply resides in fields of the 
TDndEdit object The result is not a custom control that other 
applications can use, but it is convenient for testing and ex¬ 
perimentation. 

dndedit mostly just adds new behavior rather than 
making extensive changes to existing behavior. As a result its 
window message function passes almost all incoming mes¬ 
sages on to the standard edit control, only stepping in here 
and there to monitor the state of the edit control, change the 
shape of the cursor, hide the text caret, and so on, at the 
appropriate times. 

In the C version, I do all the work myself in order to create 
a real custom control in a DLL with all the trimmings. To hold 
the extra data that the drag-and-drop edit control class needs, 
I allocate moveable memory from the local heap and store a 
handle to it in two class extra bytes. The C custom control 
registers itself under the name “WDDJ_DndEdit." 

Implementation 

Most of the rest of this article presents and explains the 
code, and the decisions that led up to it. The code listings 
alternate between Pascal and C, trying to use whichever lan¬ 
guage handled the task at hand with fewer complications. The 


Figure 4 Pascal version of CharPosToxf) 


function TDndEdit.CharPosToX(DC : HDC; Pos : integer) 

: integer; 
var 

LineNumber, LineLength 
: integer; 

Buffer 

: PChar; 

SizeP : Pint; 

Coord ; longint; 

Message : TMessage; 

begin 

PosToX := 0; 

LineNumber := GetLineFromPos(Pos); 

LineLength := Pos - GetLinelndex(LineNumber); 

{ TPW's “GetLine" won't retrieve partial lines, so 
call em_GetLine the hard way. } 

GetMem(Buffer, LineLength+2+1); 

SizeP := Plnt(Buffer); 

SizeP A := LineLength; 

Message.Receiver HWindow; 

Message.Message := em_GetLine; 

Message.wParam := LineNumber; 

Message.IParam := longint(Buffer); 

DefWndProc(Message); 

if Message.Result > 0 then 
begin 

Buffer[LineLength] := #0; 

Coord := GetTextExtent(DC, Buffer, LineLength); 

PosToX := LoWord(Coord) + TextRect.left; 

end 

else 

PosToX := 0; 

FreeMem(Buffer, LineLength+2+1); 

end; 


two implementations are quite similar, and I tried to use the 
same variable and function names in both implementations. 

The two main aspects of this custom control are a data 
structure and a set of window message functions. The data 
structure maintains state information about the drag-and-drop 
edit control, such as the enclosing rectangle of the currently 
selected text. The window message functions handle the 
changes in behavior that distinguish the drag-and-drop control 
from the standard edit control. Figure 2 shows the C version of 
the data structure associated with each instance of a drag- 
and-drop edit control. The purpose of each field will become 
clearer as you read about the window message functions. 

Like most custom controls, the dndedit code is driven by 
the window messages it receives and one way of getting ac¬ 
quainted with the code is simply to look at how the control 
handles each window message. However, some of the code is 
complex or useful to more than one window message func¬ 
tion, so I placed it in separate functions. I will begin by ex¬ 
plaining these independent functions and then move on to 
enumerating the window message functions. 

The Selection Rectangles 

The most interesting and complex problem in implement¬ 
ing the drag-and-drop control is calculating and maintaining 
the coordinates of the currently-selected text. Each time a 
UM_MOUSEMOVE occurs, dndedit has to check to see if the 
mouse is over the selected text or not and, if necessary, 
change the shape of the cursor (see the sidebar on mouse 
cursors if you are not familiar with changing the cursor shape 
under Windows). 

I decided to create two functions to handle the bulk of this 
work. SetSelectionRectf) calculates the enclosing rectangles 
of the currently selected text. It stores these coordinates in 
the drag-and-drop instance data. InSelectionf) , given a 
mouse position, uses these coordinates to calculate whether 
or not the mouse is over the selected text. 

SetSelectionRect() has by far the tougher of the two 
chores. Figure 3 shows the three cases of selected text that 
you have to consider. As the figure shows, three rectangles 
are always sufficient to describe the area enclosing any con¬ 
figuration of selected text. The instance data field SelRect 
contains these three rectangles. When no text is selected, 
these three rectangles have all their coordinates set to zero. 

SetSelectionRectf) 

Given the chore that SetSelectionRectf) has to perform, 
what information does it need to do its job? For one thing, it 
needs to know how high each line of text is, so it can calcu¬ 
late the correct rectangle height. Code elsewhere in the cus¬ 
tom control is responsible for maintaining that height in the 
instance data field FontHeight. Unfortunately, like most visual 
aspects of the edit control, Microsoft does not document that 
the edit control line height is equal to the current font's 
TM.tmHeight + TM.tmExternalLeading. It is unlikely that 
Microsoft has any need to change the relative height of edit 
control lines, but this is technically an undocumented feature 
of the standard edit control. 

SetSelectionRectf) can use EM_GETSEL to obtain the 
character positions of the currently selected text. It can also 
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use EM_LINEFROMCHAR to translate a character position into a 
line number, which saves having to extract all of the text from 
the control and count up the number of linefeeds in front of 
the first character of selected text. That still begs the impor¬ 
tant question: how can SetSelectionRectf) determine the 
client area coordinates of the selected text? 

A quick look through the standard edit control messages 
shows that it provides absolutely no information about where 
text is positioned in the client rectangle. To be fair, Windows 
3.1 did add an EM_GETFIRSTVISIBLELINE, but that still does 
not reveal the current amount of horizontal scrolling, and I 
cannot use that message anyway, since I want this control to 
work with Windows 3.0. Where can client coordinates be 
found? 

The linchpin of all the code in Set- 
SelectionRectQ is a call to GetCaret- 
Pos () . Although the standard edit con¬ 
trol will not reveal anything about client 
coordinates, whenever the text selec¬ 
tion changes, the control places the text 
caret at one end of the selected text. 

Since GetCaretPos() returns client 
coordinates, it provides part of the 
missing link that SetSelectionRectf) 
needs. SetSelectionRect() assumes 
you have called it because the selection 
has changed and, therefore, the text 
caret is positioned at the end of the 
selected text. The combination of the 
client coordinates GetCaretPos() 
returns and the character positions 
EM_GETSEL returns is the starting point 
for determining the coordinates of the 
rectangles that enclose the selected 
text. 

One more fact on this subject deser¬ 
ves mention. The text caret could be at 
either end of the selected text. There¬ 
fore, GetCaretPos() and EMjGETSEL are 
still not quite sufficient to determine 
the client coordinates of the selected 
text In order to remove this ambiguity, 
other code in dndedit is responsible for 
detecting the beginning of a selection 
(for example, due to a WM_LBUTTONDOWIf) 
and recording the starting character 
position in the instance variable 
SelectionStart. Likewise, events that 
could signal the end of a selection up¬ 
date the instance variable Selection- 
End. Therefore, when dndedit calls Set- 
SelectionRectf), it can assume that 
SelectionStart is the character posi¬ 
tion where the text caret is located. 

I wrote a helper function for Set- 
Select ionRect() called CharPosToXCoord (), 
the Pascal version of which is shown in 
Figure 4. As the name implies, 

CharPosToXCoord() converts a charac¬ 
ter offset within the edit control to an 


horizontal coordinate. CharPosToXCoord() determines the line 
length (from EM_LINELENGTH), allocates a buffer, and fetches 
the data. It can then use GetTextExtent() to determine the 
horizontal width, in client coordinates, of the text to the left of 
the specified character position. 

The C version of SetSelectionRectf) is shown in Figure 5. 
The function begins by fetching the client coordinates of the 
text caret and uses CharPosToXCoord() to fetch the virtual (it 
is important to realize that these are virtual coordinates at 
this point) horizontal coordinates of the left edge of both the 
beginning of the selected text and the end of the selected 
text The variable CaretLine is set to the physical (not virtual!) 
line number that the caret resides on. StartLine and EndLine 
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are set to the line numbers of the first and last lines, respec¬ 
tively, of the selected text. 

At this point, SetSelectionRect() has enough information 
to calculate exactly where the edit control has scrolled to, in 
virtual coordinates. It does not need this information itself 
(since it only has to calculate the virtual coordinates of the 
rectangles enclosing the selected text), but InSelectionf) will 
need this information to see if the mouse lies within the 
selected text. Accordingly, SetSelectionRect() stores the 
amount of scrolling in the instance variables HScroll and V- 
Scroll. 

Finally, the real work of SetSelectionRectf) begins. If it 
turns out that the caret was at the left, upper end of the 
selection rather than the right, lower end, SetSelection- 
Rect() has to swap some pairs of coordinates and positions 


to compensate. The rest of the function is straightforward, but 
tedious to describe in English. The selection rectangles have 
been initialized to zero, so SetSelectionRect() only bothers 
to calculate however many rectangles are needed: one, two, 
or three. 

Implementing Drag Scrolling 

When you grab selected text with the mouse, you might 
want to drag it to a spot not currently visible in the edit con¬ 
trol. You cannot click the scroll bars (if the edit control even 
has scroll bars), since releasing the mouse button drops the 
text. The solution is that when you drag the text past the 
edge of the edit control, it starts scrolling in that direction. I 
call this the "drag scrolling,” and it requires that you peri¬ 
odically scroll the window up or down, left or right, or both, 
depending on where the mouse cursor is. 

Problems similar to drag scrolling 
arise in different custom controls. For 
example, in his book Windows 3: A 
Developer's Guide, Jeffrey Richter con¬ 
structs a spin control button such that, 
if you hold the mouse button down on 
the spin button, the control has to 
generate events that scroll through the 
text in the control through different 
values. Richter’s solution is a loop that 
checks the current time via GetTick- 
Count() to see if it is time to Send- 
Messagef) another scroll message. The 
loop terminates when it detects (by 
calling GetAsyncKeyStateO) that the 
user released the mouse button. 

The problem with this solution is 
that no other Windows application can 
execute while you have the mouse but¬ 
ton down. Richter reasons that, al¬ 
though using a timer to generate scroll 
messages allows other applications to 
execute, it has two problems. First, Win¬ 
dows only offers 16 timers, and your 
control would not be able to function if 
they were all used up. Second, if other 
applications can execute between scroll 
messages, they might not yield control 
quickly enough, making the scrolling 
look jerky or even stalled. 

I found Richter's solution quite logi¬ 
cal, but aesthetically unappealing. If 
everyone writes applications that hog 
the CPU and refuse to yield control out 
of fear that some other application will 
refuse to yield control, we create a 
Catch-22 situation. So, how do the 
standard edit controls handle this situa¬ 
tion? After all, the standard edit control 
has the same problem when you press 
the mouse button to start selecting text 
and then drag it downward to select 
more than one screenful of text 



static 

void SetSelectionRect(HWND EditWindow, DNDEDIT *DndData) 
{ 

LONGRECT *SelRects = &DndData->SelRects[0]; 

POINT CaretPos; 

int StartLine, EndLine, CaretLine, NLines, Temp; 

long XStart, XEnd, XTemp; 

HDC DeviceContext; 


ZeroSelection(DndData); 
GetCaretPos(&CaretPos); 


/* init rectangles to zero */ 


CaretLine 

DeviceContext 

XStart 

XEnd 


StartLine 
EndLine 
DndData->HScroll 
DndData->VScroll 


(CaretPos.y-DndData->TextRect.top) / DndData->FontHeight; 

= GetDC(EditWindow); 

= CharPosToXCoord(EditWindow, DeviceContext, 

DndData->SelectionStart) + DndData->TextRect.left; 
= CharPosToXCoord(EditWindow, DeviceContext, 

DndData->SelectionEnd) + DndData->TextRect.left; 
LineFromPos(Edi tWi ndow, DndData->Sel ectionStart); 

LineFromPos(EditWindow, DndData->SelectionEnd); 

= XEnd - CaretPos.x; 

(EndLine - CaretLine) 


DndData->FontHeight; 


if(DndData->SelectionEnd < DndData->SelectionStart) 

( 

SWAP(XStart, XEnd, XTemp); 

SWAP(StartLine, EndLine, Temp); 

SWAP(DndData->SelectionEnd, DndData->SelectionStart, Temp); 


NLines » 1 
SelRects[0].Top 
SelRects[0].Bottom = 
Sel Rects [0] . Left 
if(NLines <= 1) 

SelRectsfO] .Right 

el se 

{ 

SelRects [0].Right 
Sel Rects[2].Left 
Sel Rects[2].Top 
Sel Rects[2].Bottom 
SelRects[2] .Right 
if (NLines > 2) 


+ EndLine - StartLine; /* # of lines selected */ 
= StartLine * DndData->FontHeight; 
SelRectsfO].Top + DndData->FontHeight; 
XStart; 


= XEnd; 


= L0NG_MAX; 

■ 0 ; 

* DndData->FontHeight * EndLine; 

« SelRects[2].Top + DndData->FontHeight; 
= XEnd; 


} 


SelRects[1].Left 
SelRectsfl] .Right 
SelRects[1].Top 
SelRects[1].Bottom 
) 


= 0 ; 

= L0NG_MAX; 

* SelRects[0].Bottom; 
= SelRects[2].Top; 


ReleaseDC(EditWindow, DeviceContext); 


) 
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Like many readers, I turn to our master Windows colum¬ 
nist, Paul Bonneau, to answer tough questions like this. Paul 
revealed that Windows controls use a single, internal “system 
timer.” This apparently functions like the normal timers, but it 
is the only such timer and a control can always count on its 
being available until the control loses the input focus (see 
Paul's column in this issue for more information). Unfortunate¬ 
ly, the system timer is undocumented and I try to avoid using 
undocumented features unless the penalty for not using them 
is fairly large. 

The solution I finally arrived at allows other applications to 
run, does not require any timers, and does not require any 
undocumented functions. When the user drags the mouse 
outside the edit control, I generate a special UM_M0USEM0VE 
message with a position of -1 inside my UM_MOUSEMOVE hand¬ 
ler and remember the current time by calling GetTick- 
Count(). I use PostMessage() to generate this event so that it 
goes into the input queue and is fetched by GetMessage(), 
giving other applications a chance to execute. Each time one 
of these "funny” UM_M0USEM0VE messages arrive, if enough 
time has elapsed, I generate a scroll event. This continues 
until the edit control receives a UM_LBUTTONUP event, which 
takes it out of the “grabbed” state. 

When I first implemented this solution, I noticed an odd 
phenomenon: if I released the mouse button outside the edit 
window, I did not receive the UM_LBUTTONUP event. Until, that 
is, I moved the mouse back over the edit control window! I 
found this thoroughly confusing, but Paul Bonneau once again 
supplied the answer. PostMessage() places its messages in¬ 
side the small message queue reserved for my application. 
“Real” events, such as mouse or keyboard events, however, 
are in the system input queue. When you call GetMessagef) 
and your small message queue is empty, only then does Win¬ 
dows check the next message in the system input queue and 
assign it to the correct application. 

The solution was to call PeekMessage(). Among its 
numerous uses, PeekMessage() allows you to determine if a 
specific type of message is waiting for you. Therefore, inside 
my UM_M0USEM0VE handler, I use PeekMessage() to see if a 
UM_LBUTTONUP is waiting for me. If it is, then I stop posting the 
funny UM_MOUSEMOVE messages so that the UM_LBUTTONUP 
waiting in the system queue will finally come through. 

Why It Shouldn’t Work! 

I was so happy with my message-posting solution to the 
dragging problem, that I had it completely implemented 
before I realized that it should not work. Windows depends 
upon cooperative multitasking — if your code never calls 
Yield() or GetMessage() or PeekMessage(), no other Win¬ 
dows applications will get a chance to use the CPU. In fact, 
other applications do not get their turn until you have 
emptied your message queue. That is why programmers who 
call Yield() periodically in hopes of giving time slices to other 
applications often get a rude surprise: if you call Yield() 
when some window messages are in the queue for your ap¬ 
plication, Windows will not yield after all. Basically, Windows 
3.x (Windows NT has solved this problem) is bound and deter¬ 
mined that input will be handled sequentially and your ap¬ 
plication will get the CPU until it finishes handling all its input. 


Every time dndedit receives its drag message (the fake 
UM_MOUSEMOVE), it posts another one. Hence, there is always 
one more message in the queue. Since the input queue is 
never empty while the user is drag-scrolling text, my solution 
does not work. Or does it? Just as I was about to pull out my 
code and go with Richter’s solution, I noticed that the Win¬ 
dows clock application was ticking away in the background 
while I was drag scrolling. I tested it with some other applica¬ 
tions and, sure enough, my drag-scrolling code really was 
yielding the CPU to other applications! 

Now I was really confused, since this meant that my un¬ 
derstanding of the Windows input model was not completely 
correct I had the chance to pose the question to several ex¬ 
pert Windows programmers during Microsoft's Win32 con¬ 
ference, and they all agreed that my method should not yield 
the CPU. Why does it work then? The truth is that I do not 
know, but I hope that someone will figure it out by next 
month, in which case I will print the answer then. 

Next month, I will complete dndedit by presenting the 
code that handles all the onerous complications of scrolling, 
drag scrolling, and positioning the text caret. □ 
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Formatting 


Robert L Hummel 

Many types of “diskette emergencies” can be handled in¬ 
telligently by an application. For example, it's relatively easy 
to politely remind the user to close the drive door rather than 
have an "Abort, Retry, ignore?” message suddenly appear in 
the middle of your data input screen. Unfortunately, not all 
diskette problems can be handled with similar ease-, in par¬ 
ticular, an unformatted diskette will usually stop even the 
most accommodating application dead in its tracks. 

Granted, formatting a diskette is a fairly straightforward — if 
tedious — process that probably represents one of the major 
interactions between a user and the operating system. But 
who is there among us who hasn't run out of formatted dis¬ 
kettes during a backup or other multidiskette operation and 
had to start from scratch? 

The obvious solution to this problem —having your applica¬ 
tion invoke the FORMAT program provided with DOS — is 
fraught with difficulty, sine eformat.com may not be available 
or locatable on the system. Even where FORMAT can be 
found, however, allocating memory and running the program 
from within your application can be complex. Clearly, format¬ 
ting a diskette from within an application is both desirable 
and problematic. The FormatDiskette() function, presented 
here, performs the physical format, creates the logical struc¬ 
ture, and marks off bad areas of a diskette using the BIOS 
diskette functions. 

The first version of FormatDiskette() appeared as part of 
an assembly language TSR developed in response to BACKUP'S 
annoying habit of requiring one more formatted diskette than 
I happened to have available. By simply pressing a hotkey, I 
was able to suspend BACKUP, format a 360Kb or 1.2Mb dis¬ 
kette, then continue. 


Robert Hummel is president of Schaefer Software, a New 
Hampshire-based consulting firm. He is the author of the Ziff- 
Davis press book PC Magazine Programmer's Technical Refer¬ 
ence: The Processor and Coprocessor and has just written a 
new book on practical assembly language programming called 
PC Magazine Assembly Language Lab Notes. 

Copyright © 1992 Robert L Hummel 
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Diskettes 


More recently (long after I’d abandoned BACKUP), I modified 
the function to add an interface for the BASIC language as well 
as support for 720Kb and 1.44Mb diskettes, in this form, the 
function appears as part of Crescent Software's QuickPak 
Professional programming library. To enhance its usability, I 
added an interface for the C language, creating a single object 
module that could be placed in a general-purpose program¬ 
ming library and linked directly with programs in each of the 
languages. This function can be combined with the Diskette- 
Type () function (W/ndows/DOS Developer’s Journal, "BIOS Iden¬ 
tification of Diskette Drives, May, 1992, pp. 45-52), to provide a 
convenient and reliable method of identifying and formatting 
diskettes. 

Using FormatDiskette() 

FormatDiskette() performs the format operation using 
BIOS functions. Consequently, it requires that you specify the 
physical drive number of the diskette drive to be used. The 
BIOS assigns numbers to drives during system initialization. 
The first diskette drive in the system is assigned the drive 
number o. The next diskette drive is numbered drive 1, and so 
on. The maximum diskette drive number permitted is 7Fh. 

As important as knowing which drive to use is knowing 
the type of drive hardware. Formatting a 360Kb diskette in a 
360Kb drive is a significantly different operation than format¬ 
ting the same diskette in a 1.2Mb drive. Fortunately, the BIOS 
functions are able to hide the gruesome details of these dif¬ 
ferences — but only if the drive can be correctly identified as 
one of the types given in Table 1. 

The next parameter that must be specified is the capacity 
to which the diskette is to be formatted, also called its media 
type. The DOS FORMAT program supports many obsolete 
capacities, including those for single-sided drives. To keep its 
code size to a minimum, FormatDiskette() supports only the 
capacities shown here for each drive: 


Drive 

Capacities 

Type 

Supported 

360Kb 

360Kb 

1.2Mb 

360Kb, 1.2Mb 

720Kb 

720Kb 

1.44Mb 

720Kb, 1.44Mb 
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Table 1 Drive Types used by FormatDisketteO 

Value 

Drive Type 

1 

360Kb, 5.25-inch, 40 tracks, 9 sectors per track 

2 

1.2Mb, 5.25-inch, 80 tracks, 15 sectors per track 

3 

720Kb, 3.5-inch, 80 tracks, 9 sectors per track 

4 

1.44Mb, 3.5-inch, 80 tracks, 18 sectors per track 


For simplicity, the desired capacity is expressed as the 
nominal number of Kb of storage on the diskette: 


Capacity Symbolic Value 

360Kb 360 

1.2Mb 1200 

720Kb 720 

1.44Mb 1440 

FormatDisketteO requires the calling program to supply the 
address of a scratch buffer of sufficient size for the structures 
that must be built during the format. This buffer is used to 
hold one complete copy of the diskette’s file allocation table 
(FAT) as well as the track buffer required by the BIOS format 
and verify services. A 360Kb diskette, for example, requires 
9*4=36 bytes for a track buffer and 2*512=1024 bytes for a 
FAT buffer, giving a total required buffer size of 1060 bytes. 
The minimum buffer size in bytes required for each media 
type is shown here: 


Table 2 Format result codes returned by 
FormatDisketteO 

0 

Format successful 

1 

Invalid disk parameter 

2 

Address mark not found 

3 

Write protect error 

4 

Requested sector not found 

6 

Disk change line active 

7 

Wrong capacity for drive 

8 

DMA overrun 

9 

DMA boundary error 

0AH 

Track 0 bad, disk is write protected, or 1.4Mb 
requested on 720k drive 

0BH 

Bad sectors found and marked 

0CH 

Media type not found 

10H 

CRC read error 

20H 

Controller failure 

40H 

Seek failure 

80H 

Drive not ready 


Capacity Minimum Buffer Size 

360Kb 1060 
1.2Mb 3644 
720Kb 1572 
1.44Mb 4680 
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When FormatDisketteO exits, it returns an integer value in 
AX that indicates a successful format or identifies the problem 
that was encountered. The complete list of return values and 
their interpretation is shown in Table 2. 

The source code listing for fdformat.asm, shown in Listing 
1, declares three public procedures. The first, Format- 
Diskette$FAR, provides the entry point for the assembly lan¬ 
guage interface and is invoked with a far call. Before calling 
the function, load the DL register with the drive number, the 
DH register with the drive type, the CX register with the 
media type, and point the ES:DI register pair to a correctly 
sized work buffer. On return, AX will contain a value indicating 
the result of the operation. A short assembly language pro¬ 
gram that shows how to call FormatDiskette$FAR from a 
medium model program is given in Listing 2. 

The FormatDiskette procedure provides the entry point 
for the BASIC language interface. In the default BASIC calling 
convention, values are passed by reference, arguments are 
pushed in left-to-right order, and the called procedure is 
responsible for removing arguments from the stack. The 
FormatDiskette procedure creates the stack frame required 
to access the passed parameters and loads them into the ap¬ 
propriate registers. Control is then passed to the Format- 
Diskette$FAR procedure. On return, the BASIC exit protocol is 
performed, destroying the stack frame, and control is returned 
to the calling program. Listing 3 shows a short BASIC program 
that demonstrates the use of the FormatDisketteO proce¬ 
dure to format a diskette. 

To satisfy the C language interface, a new public symbol is 
created with an underscore prepended to the procedure 



Page 50 — Windows/DOS Developer’s Journal 


October 1992 






























name. (This convention allows source code written for either C 
or BASIC to reference the function using the same name.) Un¬ 
like BASIC, the default C convention is to pass arguments by 
value and to have the caller remove arguments from the 
stack. The _FormatDiskette procedure creates the required 
stack frame, loads the format parameters into the appropriate 
registers, then calls the FormatDiskette$FAR procedure. On 
return, the standard C exit protocol is performed and control is 
returned to the calling program. The sample program in Listing 
4 shows a short C program that demonstrates use of the 
_FormatDiskette procedure. 

DOS Floppy Diskette Formats 

Regardless of a diskette's capacity (a somewhat arbitrary 
number established by the drive and the operating system), 
its structure is essentially the same. Data is recorded on each 
of the diskette's surfaces, called head s or sides, in a series of 
concentric circles, called tracks. Each circular track is further 
subdivided into sectors. A disk’s total storage capacity may be 
simply determined by multiplying the number of diskette sur¬ 
faces by the number of tracks per surface by the number of 
sectors per track. While the drive hardware can support many 
different physical diskette structures, DOS comes with drivers 
for only a few of the possible combinations. 

To be readable by DOS, a diskette must have a logical 
structure imposed on its physical structure. While physical for¬ 
mats vary, DOS expects the logical structure of all diskettes to 
be identical. The DOS FORMAT program divides the sectors of a 
diskette into four sections, each of which has a unique pur¬ 
pose. The four sections are, in the order they appear on the 
disk, the boot record, the file allocation table (FAT), the root 
directory, and the data area. The size of each of these sections 
varies, depending on the diskette’s capacity, but the structure 
and order remain constant. 

The boot record usually occupies a single sector, and is 
always located in the first logical sector (sector 0) of the disk. 
The boot record contains a small data area, the BIOS 
Parameter Block, that delineates the physical parameters of 
the disk. The boot record also contains a short bootstrap pro¬ 
gram that may be loaded by the BIOS when the PC is initial¬ 
ized. 

The FAT follows the boot record. The contents of the FAT 
describe how the disk's data sectors are allocated. Each entry 
in the FAT indicates that an area of the diskette is either free, 
in use, or unusable (typically due to defects on the disk). In 
most cases, two identical copies of the FAT are created and 
maintained by DOS. 

The root directory is a fixed-length structure that contains 
a list of directory entries. Each entry contains a file's name, 
attributes, time and date of most recent modification, and a 
pointer to the first group of data sectors used by the file. 

Programs and program data are stored in the remainder of 
the disk's sectors, known as the data area. Data sectors are 
allocated to files as required. In general, allocating and track¬ 
ing individual data sectors on a large diskette would require 
so much overhead that file handling efficiency would plum¬ 
met. To improve performance, data sectors are generally allo¬ 
cated in groups called clusters. The number of sectors in a 
cluster is dependent on the type of the disk. A 1.44MB floppy, 
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for example, has 1 sector per cluster. Regardless of the 
capacity of the diskette, the number of sectors per cluster will 
always be a power of 2. 

How FormatDisketteO Works 

To properly program the drive hardware for a format 
operation, it’s necessary to know both the type of drive and 
the media type. In general, FormatDisketteO doesn’t check 
the values you pass to it for validity. It won’t, for example, 


screen out an illegal drive number or a drive that doesn’t 
exist. Ensuring that these parameters are correct is up to you. 
However, as a side effect of its identification of drive and 
media combination, the function does verify that the media 
can be formatted by the indicated drive type. If the drive type 
and media are compatible, the SI register is set to point to 
the correct media table, a data area that contains the 
parameters needed to format the disk. If not, the function ter¬ 
minates with an error code of 7. 


Listing 1 


-------- 

ERRSDMA BNDRY 


EQU 

9 

;DMA boundary error 


FDFORMAT.ASM 

ERRJMED TYP NOT 

FND 

EQU 

0CH 

;Media type not found 


Copyright (c) 1992 Schaefer Software, Robert L. Hummel 

ERRJCRC RD ERR 


EQU 

10H 

;CRC read error 



ERRSCTRLR FAIL 


EQU 

20H 

jController failure 


FormatDisketteO is a function that attempts to format a floppy disk 

ERRJSEEK FAIL 


EQU 

40H 

;Seek failure 


drive to the requested (capacity) using BIOS calls. It returns an 

ERRSDRV NOT RDY 


EQU 

80H 

;You'll get this if door open 


integer value that indicates whether the format was successful. If 








not, the return value identifies the type of error as defined in the 








equate section below. 


I define these additional errors. 



Notes: 


IRRSINV CAP 


EQU 

7 

;Wrong capacity for drive 


1. This routine operates on PHYSICAL diskette drives, not logical 

ERRSTRK 0 BAD 


EQU 

0AH 

;Bad disk/cap=l.4 w/720k disk 


drives. 






; or write protected disk 


2. This routine makes no attempt to identify or check the drive. 

ERRSBAD SECT 


EQU 

0BH 

;Bad sectors found and marked 


drive type, or media. You must call it with the correct drive 








number, type, and ensure the correct media is in use to ensure a 








successful format. 


Drive types. 






3. Only the standard DOS capacities are supported. Altering these to 








produce custom formats, however, is quite simple. 

DRIVE 360 


EQU 

1 



4. Bad sectors are detected and marked as such in the FAT using the 

DRIVE 1200 


EQU 

2 



sector bad = track bad DOS convention. 

DRIVE 720 


EQU 

3 



5. Compatible with Microsoft medium model. 

DRIVE 1440 


EQU 

4 



Usage: 








Result*FormatDiskette(DrvNum,DrvType,Media,SEG Buf) 


Program equates. Change if required. 



where 








DrvNum * (16-bit integer) physical drive number 

RETRY0 


EQU 

5 

;Retries for track 0 


0 * 1st physical diskette 

RETRY 


EQU 

3 

jRetries for other tracks 


1 = 2nd physical diskette 








2 * 3rd physical diskette 


n 

n 

M 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

====== 

======== 

ii 

n 

ii 

ii 

ii 

ii 

n 

H 

II 

II 

=============================== 


etc. 


A convenient 

alias 

for low 

memory. 



DrvType * (16-bit integer) type of drive (maximum capacity) 


.0MEM 

SEGMENT AT 

0000H 



1 = 360k 5.25 M 








2 * 1.2M 5.25 H 



0RG 

(1EH 

* 4H) 

;Int lEh points to disk base 


3 * 720k 3.5" 

DISK BASE 

DD 

7 




4 = 1.4M 3.5" 









L0MEM 

ENDS 





Media = (16-bit integer) type of media being formatted 








360, for 360K 5.25" 






N 

II 

N 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

U 

II 

II 

II 

II 

II 

II 

II 


1200, for 1.2M 5.25" 


DGR0UP addressing compatible with medium memory model. DS=SS=DGR0UP 


720, for 720K 3.5" 








1440, for 1.44M 3.5" 


DGR0UP 

GROUP 

DSEG.USEG 




DSEG 

SEGMENT WORD 

PUBLIC 

'DATA' 


SEG Buf = Far pointer to scratch buffer 








(minimum size in bytes shown for each format) 








( 9*4)+(2*512)=1060, for 360K 5.25" 


Each entry defines 

all the 

information for a particular disk format. 


(15*4)+(7*512)=3644, for 1.2M 5.25" 


Feel free to 

insert 

your own company name as the OEM System ID. 


( 9*4)+(3*512)=1572, for 720K 3.5" 








(18*4)+(9*512)=4680, for 1.44M 3.5" 


Media info/boot record for 360K 5.25" 

floppy. 


Result = (16-bit integer) 


1EDIA 360 

DB 

50H 


; 0, Format gap length 


0, diskette formatted successfully 



DB 

40 


; 1, Number of tracks 


> 0, see error table 



DB 

7 


; 2, Root dir sectors 


HJBLIC FormatDiskette -.BASIC, PASCAL (FAR) 



DB 

0EBH 

2EH.90H 

; 3, JMP 30H, NOP 

PUBLIC FormatDiskette ;C (FAR) 



DB 

"SCHAEFER" 

; 6, System ID 

PUBLIC FormatD1skette$FAR ;ASM (FAR) 



DW 

512 

;200H 

;14, Bytes per sector 




DB 

2 


;16, Sectors per cluster 


ii 

ii 

ii 

n 

ii 

u 

ii 

ii 

ii 

ii 

it 

m 

ii 

ii 

n 

u 

ii 

ii 

H 

ii 

ii 

ii 

n 

ii 

ii 

n 

n 

ii 

ii 

ii 

ii 

n 

ii 

ii 

n 

ii 

ii 

ii 

ii 

n 

ii 

ii 

n 

M 

ii 

n 

n 

n 

n 

n 

ii 

n 

ii 

ii 

ii 

n 

ii 

ii 

n 

n 

ii 

ii 

ii 

ii 

n 

ii 

n 

n 

n 

ii 



DW 

1 


;17, # reserved sectors 


Equates 



DB 

2 


;19, # copies of FAT 





DW 

112 

;70H 

;20, # root directory 


These error returns are defined by the BIOS. 






;entries 





DW 

2*9*40 ;2D0H 

;22, Total # of sectors 

ERR$INV DISK PARM EQU 1 ;Invalid disk parameter 



DB 

0FDH 


;24, Format ID 

ERRSADR MARK NOT FND EQU 2 ;Address mark not found 



DW 

2 


;25, Sectors per FAT 

ERR$WR PROT ERR EQU 3 jWrlte protect error 



DW 

9 


;27, Sectors per track 

ERRSREQ SEC NOT FND EQU 4 ;Requested sector not found 



DW 

2 


;29, Number of heads 

ERRSDISK CHG LN ACTV EQU 6 ;D1sk change line active 



DD 

0 


;31, Special reserved 

ERRJDMA OVRRUN EQU 8 ;DMA overrun 






;sectors 
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Once the correct media table for the combination has been 
identified, the BIOS diskette drive parameter table, or disk 
base, must be updated. The address of the disk base is stored 
in the doubleword at 0:522h, the vector for interrupt lEh. The 
two parameters that must be set are the format gap length 
and the number of sectors per track. (Of course, the original 
values for these parameters are saved and restored at the 
end of the function's execution.) Both of these values are 
retrieved from the media table. To ensure that the BIOS will 


use these new values, the hardware is then reset using the 
Reset Diskette System function (Int 13, AH=0). 

In general, both 1.2Mb and 1.44Mb drives are upwardly 
compatible with 360Kb and 720Kb drives, respectively. The 
BIOS achieves this compatibility by programming the drives to 
emulate the desired drive type, adjusting low-level drive 
parameters such as the rotation speed of the drive and how far 
the stepper motor moves between tracks. The logic to perform 
this operation is encapsulated in the SET_MEDIA procedure. 


Listing 1 continued 


Media info/Boot record for 1.2M 5.25" floppy. 


MEDIA 1200 DB 

54H 


;Format gap length 

DB 

80 


jNumber of tracks 

DB 

14 


;Root dir sectors 

DB 

0EBH.2EH.90H 


;JMP 30H, NOP 

DB 

"SCHAEFER" 


;System ID 

DW 

512 ;200H 


jBytes per sector 

DB 

1 


;Sectors per cluster 

DU 

1 


;# reserved sectors 

DB 

2 


;# copies of FAT 

DW 

224 ;E0H 


;# root directory entries 

DW 

2*15*80 ;960H 


jTotal # of sectors 

DB 

0F9H 


jFormat ID 

DW 

7 


;Sectors per FAT 

DW 

15 


;Sectors per track 

DW 

2 


jNumber of heads 

DD 

0 


•.Special reserved sectors 

; Media info/Boot record for 720K 3.5" 

floppy. 


MEDIA 720 DB 

50H 


jFormat gap length 

DB 

80 


;Number of tracks 

DB 

7 


;Root dir sectors 

DB 

0EBH.2EH.90H 


;JMP 30H, NOP 

DB 

"SCHAEFER" 


;System ID 

DW 

512 ;200H 


;Bytes per sector 

DB 

2 


jSectors per cluster 

DW 

1 


;# reserved sectors 

DB 

2 


;# copies of FAT 

DW 

112 ;E0H 


;# root directory entries 

DW 

2*9*80 ;5A0H 


;Total # of sectors 

DB 

0F9H 


;Format ID 

DW 

3 


;Sectors per FAT 

DW 

9 


jSectors per track 

DW 

2 


jNumber of heads 

DD 

0 


•.Special reserved sectors 

; Media info/Boot record for 1.44M 3.5 

floppy 


MEDIA 1440 DB 

6CH 


;Format gap length 

DB 

80 


jNumber of tracks 

DB 

14 


;Root dir sectors 

DB 

0EBH,2EH,90H 


;JMP 30H, NOP 

DB 

"SCHAEFER" 


;System ID 

DW 

512 ;200H 


jBytes per sector 

DB 

1 


jSectors per cluster 

DW 

1 


;# reserved sectors 

DB 

2 


;# copies of FAT 

DW 

224 ;E0H 


;# root directory entries 

DW 

2*18*80 ;640H 


jTotal # of sectors 

DB 

0F0H 


jFormat ID 

DW 

9 


jSectors per FAT 

DW 

18 


•.Sectors per track 

DW 

2 


•.Number of heads 

DD 

0 


;Special reserved sectors 

; This bootstrap routine is the common 

suffix 

for each boot record. 

; It is loaded beginning at offset 30h 

in the boot record. It displays 

; a message saying that this is not a 

bootable 

disk. 

B00TC0DE LABEL 

BYTE 


joffset 30h 

CLI 



;No interrupts 

SUB 

AX, AX 


;AX = 0 


B00TMSG 


MOV 

SS.AX 

jCreate stack 

MOV 

SP.7C00H 


MOV 

DS.AX 

;DS=0000 

MOV 

SI,OFFSET 

B00TMSG - OFFSET B00TC0DE + 7C30h 

MOV 

CX,OFFSET 

B00TMSGEND - OFFSET B00TMSG 

CLD 


jString moves forward 

L0DSB 


;AL=DS:[SI++] 

MOV 

AH.0EH 

-.Write TTY 

MOV 

BX,7 


INT 

10H 

; thru BIOS 

LOOP 

$-8 

•.Create relative label 

SUB 

AX, AX 

;Wait for key 

INT 

16H 

; thru BIOS 

MOV 

WORD PTR DS:[472H],1234H ;Warm boot 

DB 

0EAH 

;Far jump 

DW 

0.0FFFFH 

; to RESET routine 

DB 

13,10."You 

cannot boot from this disk; it does' 

DB 

13,10,"not 

contain the DOS system files." 


Cand C++ DOCUMENTATION 


C-METRI( T ($59 ) ,CO MPLEXITY / QUALITY 

• Calculates cyclomatic path complexity for functions and 


'cyciomatic' path complexity 1 

• Counts lines with comments, code, and 'C' statements 


system 


filel main 

file2 

—sub2 

file2 

1—sub3 

file2 

1—sub4 

filel 

— main {recursv} 


--- Ibryl, Ibry2 


C-CALL ($69) FUNCTION HIERARCHY 


1 Tree-Diagram showing function hierarchy 

■ Table-Of-Contents of functions versus files 

■ Summary and detailed cross-reference of functions 


C-CMT™($69) FUNCTION COMMENT 

7*FF**** ******** ************* 
sub2 USERS: main 

CALLS: sub3 sub4 
PARAM: argl arg2 
LOCAL: varl 

GLOBL: var2 var3 

• Generates and inserts function comment blocks 

• Can be re-run to update the comment blocks 

• Retains any user-generated comments 

while (i<j) 

if(i<k) { 

C-LIST 1$69) LISTS OR REFORMATS 


, ) 
else 

I l-m; 


■ Optional line numbers, page numbers, and titles 
• Reformats source to various standardized formats 


C-REF™($59) CROSS-REFERENCES IDENTIFIERS 


■ Local/parameter/global/define summary or cross-reference 

■ Produces class-hierarchy tree-diagram for C++ classes 


SPECIAL: ($199) C-POCT DOS 


P ackae 

all C-DO( 


e ($325 Value) 


All 5 programs fully integrated as 1 overall C-DOC program 

• Processes multiple directories/files up to 15,000 total lines 

• Unconditional 30-day money-back guarantee of satisfaction 

NEW: C-POCTProfessional ($299); DOS. OS/2. Windows 

• Processes 150,000 lines, 3-ring binder/case, 2-pass deferred reports 


!! NEW 5.0 !! Point-and-click G.U.I. operation !! 


SOFTWARE BLACKSMITHS INC 

6064 St Ives Way, Mississauga 
ONT Canada L5N-4M1 


Voice/Fax: (4161-858-4466 
Demo/BBS: (416)-858-1916 


□ Request 134 on Reader Service Card □ 


October 1992 


Windows/DOS Developer's Journal — Page 53 














































On PCs that have BIOS support for 1.44Mb drives, the Set 
Media Type for Format function (Int 13h, AH=18h) must be 
called before formatting begins. The function accepts drive 
parameters and, if the passed drive parameters can be 
matched to one of its internal tables, returns successfully with 
the ES:DI register pair pointing to the correct disk base (be¬ 
cause the program has already modified the disk base direct¬ 
ly, this pointer is simply discarded). 


If the Set Media function is not supported by the BIOS, and 
if a the requested media is a 1.44Mb diskette, SET_MEDIA 
returns an error code indicating an invalid capacity. If the BIOS 
Set Media function is supported, but reports an illegal 
drive/media combination, SET_MEDIA passes back the same 
error. 

For media other than 1.44Mb, the Set Direct Access Storage 
Device (DASD) Type function is called. On all ATs, all PS/2s, and 
on XTs with a BIOS dated 1/10/86 or later, this function is used 


Listing 1 

continued 



DB 

13,10,"Replace 

or remove the diskette and " 


DB 

13,10,"press Enter ",17,217," to reboot.",13 

B00TMSGEND 

EQU 

$ 



DB 

"Copyright (c) 

1992, Robert L. Hummel" 

B00TC0DELEN 

EQU 

$-0FFSET B00TC0DE 

DSEG 

ENDS 



; Unitialized data. 

USEG 

SEGMENT WORD PUBLIC 

* BSS * 

SAVE BASE 

DW 

1 DUP (?) 


SBUFPTR 

DW 

1 DUP (?) 

;ES:offset of sector buffer 

DRIVENUM 

DB 

1 DUP (?) 

;Physical drive number 

DRIVETYPE 

DB 

1 DUP (?) 

;Type of drive 

FUNCTION 

DB 

1 DUP (?) 

;Used by format/verify proc 

ERROR 

DB 

1 DUP (?) 

;Set if bad tracks detected 

HEAD 

DB 

1 DUP (?) 

;Used by BI0S WRITE 
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even know about. 

PLUS —Gain access to a critical 
bibliography that will become an 
indispensible resource to you. 

HIGHLY TECHNICAL 
HIGHLY FOCUSED 


MS-dos 

system programming 


Every entry is written by 
working programmers for 
working programmers. In¬ 
cluded are compiler- 
specific insights that will 
save you hours of work. 

Find out how to exploit spe¬ 
cial Turbo C features to 
simplify device drivers. Plus 
a bibliography designed to 
help the serious program¬ 
mer develop a personal 
library of MS-dos literature. 

Released July 1991, 240 pp. ISBN 0-923667-20-2 


edited by 
ROBERT WARD 


Nitty Gritty Coverage on 
These How-to Topics 


dIrectly Windows/DOS 

FROM 


Critical Error Handlini 
Customizing the DO 
Boot Strap 
Interrupt-Driven I/O 
Manipulating 
Environmental Variables 
Event Timing 
Writing TSRs 
Controlling the Disk 
Hardware 
Writing Device /\ 

Drivers __/ / 

ONLY 

$24® 


I DEVELOPER'S JOURNAL 



913 - 841-1631 

FAX: 913-841-2624 



TRACK 

DB 

1 DUP (?) 

;Used by BIOS WRITE 

SECT 

DB 

1 DUP (?) 

;Used by BIOS WRITE 

NSECT 

DB 

1 DUP (?) 

;Used by BIOS WRITE 

USEG 

ENDS 




Code segment. 


CSEG SEGMENT BYTE PUBLIC 'CODE 1 

ASSUME CS:CSEG, DS.-DGROUP, ES:N0THING, SS:DGR0UP 


FormatDiskette$FAR 

Copyright (c) 1992 Schaefer Software, Robert L. Hummel 


The common assembly routine called by the HLL interface routines. 
May also be called directly from assembly language. 

All arguments are passed via register. 


Entry: 


Exit: 


CX * Valid capacity code as defined in header 
DH = Valid drive type as defined in header 
DL = Physical drive number (not checked) 

ES:DI = Far pointer to scratch buffer; size defined in header 
AX = Result as defined in header 


Changes: AX BX CX DX SI DI 


FormatDiskette$FAR PROC FAR 

ASSUME CS:CSEG, DS:DGR0UP, ES:N0THING, SS:DGR0UP 


Initialization. 



OLD 


;String moves forward 


SUB 

AX, AX 

;Create a zero 


MOV 

[ERROR],AL 

;Initialize error code 


MOV 

[DRIVENUM],DL 

;Save drive number 


MOV 

[DRIVETYPE],DH 

; and type 


MOV 

[SBUFPTR],01 

;Save buffer offset 

The requested capacity (CX) must be supported by the drive type (DH). 


CMP 

DH,DRIVE 1200 

;Check drive type 


JA 

FD 1C 

;type >2 if 3.5" drive 


JB 

FD_1A 

;type <2 if 360K 


MOV 

SI,OFFSET DGR0UP:MEDIA 

1200 ;Media = 1.2M 


CMP 

CX,1200 

;I.2M in 1.2M? 


JE 

FD IE 


FD 1A: 





MOV 

SI,OFFSET DGR0UP:MEDIA 

360 ;Media = 360K 


CMP 

CX.360 

;360K in either 


JE 

FD IE 


Error: Drive 

and capacity do not match. 


FD_1B: 

MOV 

AL.ERRSINV CAP 

;Put error code in AL 


JMP 

FD_EXIT 


Test for 3.5 

drives. 




FD 1C: 


CMP DH,DRIVE 720 

JE FD ID 


;Is it 720k drive? 


MOV SI,OFFSET DGR0UP:MEDIA_1440 ;Assume 1.4M 
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to prepare the hardware to format 1.2Mb media in a 1.2Mb 
drive or 360Kb media in either a 360Kb or 1.2Mb drive. On all 
but the 6/10/85 AT BIOS, the function also supports pre-format 
preparation for 720Kb media in a 720Kb drive. As before, if a 
drive/media combination is requested that is not supported 
by the BIOS, an error code is return. 

If the call to SET_MEDIA is successful, FormatDiskette() 
fills the first portion of the scratch buffer (supplied by the 
caller) with a full-size image of the diskette's FAT and initial¬ 


izes that area to contain all zeros (a zero value in a FAT entry 
indicates that the cluster pointed to by the entry is available). 
If an unreliable area of the diskette is found during the format 
operation, the corresponding clusters in the FAT buffer will be 
set to indicate that the clusters are unusable. 

The Physical Format 

It's probably no coincidence that all DOS diskette logical for¬ 
mats place their critical structures on track 0 of the diskette. If 


Listing 1 continued 


CMP 

CX,1440 

;1.4M in 1.4M? 

JE 

FD IE 


FD ID: 



MOV 

SI,OFFSET DGROUP:MEDIA 720 ;Media = 720K 

CMP 

CX.720 

;720k in either 

JNE 

FD IB 


FD_1E: 



; Before altering the 

disk base parameters as required for this format. 

; save the current values for later restoration. 

PUSH 

ES 

;Save register 

MOV 

ES.AX 

;Point ES to low memory 

ASSUME ES:LOMEM 


LES 

BX.ES:[DISK BASE] 

;ES:BX -> disk base 

ASSUME ES:NOTHING 


MOV 

CH,[SI] 

;Format gap length 

MOV 

CL,[SI+27] 

;Sectors per track 

XCHG 

CH,ES:[BX+7] 

;Change values 

XCHG 

CL,ES:[BX+4] 

; as required 

MOV 

[SAVE_BASE],CX 

;Save old values 

POP 

ES 

;Restore register 

ASSUME ES:NOTHING 


; Reset the diskette system. (At the moment 

AH=0 and DL=DRIVENUM.) 

I NT 

13H 

;Reset thru BIOS 

; Attempt to set the 

correct media/drive combination. A failure here 

; aborts the entire format. Returns its own 

error code in AL if failed. 

CALL 

SET MEDIA 

•.Return in AL if CY 

JC 

FD_2B 


; Initialize the work 

buffer. All zeros are 

written to intialize the 

; FAT buffer. The track buffer starts right after the FAT buffer. 

MOV 

AX,[SI+14] 

;Bytes/sector 

MUL 

WORD PTR [SI+25] 

;* Sectors/FAT 

MOV 

CX.AX 

;= Bytes to init 

SUB 

AL.AL 

;Store zeros 

REP 

STOSB 

; to ES:DI (buffer) 

; On all current floppy formats, track 0 contains all the critical 
; structures for the diskette. If track 0 cannot be formatted 

; successfully, the entire format operation 

is aborted. 

MOV 

BX.DI 

;Point ES:BX to buffer 

MOV 

DL,[DRIVENUM] 

;Drive 

SUB 

CH,CH 

;Track 0 

SUB 

DH.DH 

;Head 0 

MOV 

AL,[SI+27] 

;Sec/track 

MOV 

AH.RETRYO 

;Retries 

CALL 

FORMAT TRACK 

;Format track 0, Head 0 

JC 

FD_2A 


CALL 

VERIFY TRACK 

; and verify it 

JC 

FD_2A 


INC 

DH 

;Next head 

CALL 

FORMAT TRACK 

•.Format track 0, Head 1 

JC 

FD_2A 



FD_2A: 

CALL 

JNC 

VERIFY TRACK 

FD_2C “ 

; and verify it 

FD_2B: 

MOV 

AL,ERRSTRK_0_BAD 

;Error msg if failed 

FD 2C: 

JMP 

FD_EXIT 



Format a full track of this disk. Partial formats of tracks aren't 
supported (the same as DOS's format). Use fewer retries since the 
disk should already be spinning and warmed up. 


DEC 

DH 

;Head 0 

INC 

CH 

;Track 1 

MOV 

AH,RETRY 

•.Retries 

MOV 

AL,[SI+27] 

•.Sector per track 

CALL 

JC 

FORMAT TRACK 

FD_3B " 

;May change AX 

CALL 

VERIFY JRACK 

;May change AX 



Source Code Generating Graphics 
Editor and Screen Prototype Tool 
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track 0 can be formatted successfully, enough information can 
be placed on the diskette to make the diskette identifiable to 
DOS. Conversely, if track 0 cannot be formatted successfully, 
the diskette can never be used by DOS. Because of the impor¬ 
tance of track 0 to the logical format, its physical format is 
given extra attention. 

The FORMA T_ TRACK procedure, as its name implies, formats 
a single track on a single side of the diskette. To do so, it uses 
a portion of the scratch buffer to construct an array of sector 
address fields called the track buffer. Each address field com¬ 
prises the following four bytes-, track number, head number, 
sector number, and a value representing the number of bytes 


per sector. To format track 3 on side 1 of a 1.2Mb diskette, for 
example, the track buffer would be 60 bytes long and contain 
the following values: 

3 112 

3 12 2 

3 13 2 

o o o • 

• © • • 

• • • • 

3 1 15 2 


Listing 1 continued 


JNC FD 3C 


If the verify operation fails, mark the entire track bad. Although 
the track could be checked sector by sector, DOS doesn't do it and 
most people just throw away a diskette if it has any bad sectors. 


FD 3B: 


MOV 

[ERROR],ERRSBAD SECT 

;Set return code 

CALL 

MARK_TRACK_BAD 

;Can't fail 

; Advance to the next 

head. If HEAD is now 1, 

repeat the loop with the 

; same value for the 

track. Otherwise, bump the track counter as well. 

FD 3C: 



XOR 

DH,1 

;Toggle head 0/1 

JNZ 

FD_3A 

;If head 1, rpt track 

INC 

CH 

;Next track 

CMP 

CH,[SI+1] 

;Compare # tracks 

JB 

FD 3A 

;Below since 0-based 

; Physical format is complete. Perform the logical format to make this 

; a DOS disk. The FATs are written first since 

the buffer area is 

; required to build the other information areas. 

MOV 

BX,[SBUFPTR] 

;Ptr to buffer 

MOV 

AL,[SI+24] 

;Media ID byte 

MOV 

ES:[BX],AL 

;Save in FAT 

MOV 

WORD PTR ES:[BX+1],-l 

; in first 2 entries 

MOV 

AL,[SI+25] 

;Sectors per FAT 

MOV 

CX.0002H 

•.Track 0, Sector 2 

SUB 

DH.DH 

;Head 0 

MOV 

DL,[DRIVENUM] 

;Drive number 

CALL 

BIOS WRITE 

;1st copy 

JC 

FD_EXIT 


MOV 

AL,[SI+25] 

;Sectors per FAT 

CALL 

BIOS WRITE 

;2nd copy 

JC 

FD EXIT 


; Zero out one sector of the buffer. Write the 

root directory one 

; sector at a time right after the FATs. 


PUSH 

CX 

;Preserve track/sect 

MOV 

CX,[S1+14] 

;Bytes per sector 

SHR 

CX,1 

; to words 

MOV 

DI.BX 

;Start of buffer 

SUB 

AX, AX 

;Write zeros 

REP 

STOSW 

;Clear buffer 

POP 

DI 

;Hold track/sect 

SUB 

CH.CH 


MOV 

CL,[SI+2] 

;CX = # root sectors 

FD 8: 



XCHG 

CX.DI 

;CX = track/sect for 

write 



MOV 

AL,1 

;Write 1 sector 

CALL 

BIOS WRITE 

;Write to disk 

JC 

FD_EXIT 


XCHG 

CX,DI 

;CX = count for loop 

LOOP 

FD 8 



; Construct the boot record and write it to 

the first sector. 

PUSH 

SI 

;Save pointer to media 

MOV 

DI.BX 

;ES:DI = dest 

MOV 

WORD PTR ES:[DI+lFEh],0AA55H ;Boot signature 

ADD 

SI.3 

;Point to prefix 

MOV 

CX.32/2 

;Number of words 

REP 

MOVSW 

;Copy them 

LEA 

DI, [BX+30H] 

•.Destination 

MOV 

SI,OFFSET DGR0UP:B00TC0DE ;Source 

MOV 

CX.BOOTCODELEN 

;Length 

REP 

MOVSB 

;Move 'em 

MOV 

AL, 1 

;Write 1 sector 

MOV 

CX.0001H 

;Track 0, Sector 1 

SUB 

DH.DH 

•.Head 0 

MOV 

DL,[DRIVENUM] 

;Drive number 

POP 

SI 

;Restore media pointer 

CALL 

BIOS WRITE 

;Write to disk 

JC 

FD EXIT 


; The physical and basic logical format are 

done. Other operations. 

; such as labeling the 

disk, can be done at 

the DOS level. 

MOV 

AL,[ERROR] 

;Retrieve any error 

FD EXIT: 



SUB 

AH, AH 

;AH = 0 

Restore the original 

values found in the disk base. 

PUSH 

ES 

;Preserve register 

SUB 

DX.DX 

;Create 0 

MOV 

ES.DX 

;Address low memory 

ASSUME ES:LOMEM 


LES 

DI,ES:[DISK BASE] 

;ES:DI -> base 

ASSUME ES:NOTHING 


MOV 

BX,[SAVE BASE] 

;Retrieve old values 

MOV 

ES:[DI+7],BH 

jRestore old base 

MOV 

ES:[DI+4],BL 


POP 

ES 

•.Restore register 

ASSUME ES:NOTHING 


Exit to caller. 

RET 



FormatDiskette$FAR 

ENDP 


SET_MEDIA (Near, Internal) 

Entry: 



DS:SI -> media 

table 



Exit : 

CF = NC, success 

CF = CY, failure 
AL = error code 


Page 56 - Windows/DOS Developer’s Journal 


October 1992 


































The last 2 in each field represents the 512-bytes-per-sector 
value used by all DOS standard formats. 

When the track buffer has been constructed, FOR- 
MAT_TRACK calls the BIOS Format Track function (Int 13h, 
AH=5). If the BIOS reports that the format operation failed, FOR- 
MAT_TRACK will automatically reset the diskette system, call 


SETMEDIA, and retry the operation up to four additional times 
(the retry count for track 0 is determined by the equate 
RETRYO). Retries are necessary simply because the diskette 
motor requires a finite amount of time in which to reach 
operating speed. Not allowing the diskette to come up to 


Listing 1 continued 


Changes: AX 


SET MEDIA PR0C 

NEAR 


ASSUME CS:CSEG, DS:DGR0UP, ES:NOTHING, 

SS:DGR0UP 

PUSH 

BX 

;Save used registers 

PUSH 

CX 


PUSH 

DX 


PUSH 

DI 


PUSH 

ES 


PUSH 

AX 

;May get discarded 

Attempt to set the 

correct media/drive combination using BIOS 

function 18h. This 

function is supported on late model XTs, ATs, and 

all PS/2s. If successful, the function returns ES:DI pointing to a 

useable disk_base 

for the specified media, but we ignore it. 

MOV 

AH.18H 

;Set media for format 

MOV 

DL,[DRIVENUM] 

; for this drive 

MOV 

CH,[SI+1] 

{Number of tracks 

DEC 

CH 

;0-based 

MOV 

CL,[SI+27] 

{Sectors per track 

INT 

13H 

; thru BIOS 

ASSUME ES:N0THING 


JNC 

SM_EXIT 


If the function was supported, but it still failed, bomb out with 

error code. 



MOV 

AL.AH 

;Error code in AL 

CMP 

AL,1 

;1 * invalid command 

JNE 

SM ERR 


If Set Media failed because it wasn't supported, this BIOS doesn't 

support and we can 

't format a 1.44M diskette. 


MOV 

AL.ERRSINV CAP 

;Specify error 

CMP 

SI,OFFSET DGR0UP:MEDIA 

1440 {Check media 

JE 

SM ERR 


Use function 17h, 

Set DASD (Direct Access Storage Device) type. 

AL = 1, to format 

360K in 360K 


2, to format 

360K in 1.2M 


3, to format 

1.2M in 1.2M 


4, to format 

720K in 720K (not supported 

on all BIOSs) 

MOV 

AH.17H 

;Set DASD type 

MOV 

0L,[DRIVENUM] 

; for this drive 

MOV 

AL,[DRIVETYPE] 

; to this type 

CMP 

AL,3 

•.Change type 3 to 4 

JE 

SM_4A 


CMP 

AL,2 

{Change 2 to 3 if... 

JNE 

SM_4B 


CMP 

SI,OFFSET DGR0UP:MEDIA 

1200 {...Cap = 1.2M 

JNE 

SM 4B 


SM 4A: 



INC 

AL 

{Adjust argument 

SM 4B: 



INT 

13H 

{ thru BIOS 

JNC 

SMJXIT 


; If supported, but 

still failed, bomb out with 

error code. 

MOV 

AL.AH 

{Error code in AL 

CMP 

AL.l 

{1 = invalid command 

JNE 

SM ERR 



If Set DASD failed because it wasn't supported, we can't format a 
720k or 1.2M diskette (if that's what was requested). 


MOV AL,ERR$INV_CAP ;Assume error 



CMP 

SI,OFFSET DGR0UP:MEDIA 360 {Check medi 


JE 

SM_EXIT 


SM_ERR: 





STC 


{CF = 1, failure 


POP 

BX 

{Discard AX 


JMP 

SHORT SM_5 


SM_EXIT: 

CLC 


{CF * 0, success 


POP 

AX 

{Keep AX 

SM_5: 





POP 

ES 

{Restore registers 

ASSUME 

ES:NOTHING 



POP 

DI 



POP 

DX 



POP 

CX 



POP 

BX 



RET 



SET MEDIA 

ENDP 




F0RMAT_TRACK (Near, Internal) 


Entry: 

AH = times to retry if error 
AL ■ sectors per track 
CH = track 
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speed is the most common cause of failure at this point in the 
format process. 

When the BIOS Format Track function indicates success, it 
is simply saying that the attempt to format the track was 
successful, not that the track was successfully formatted. If 
you were to remove every drop of magnetic coating from the 
plastic diskette, for example, the Format Track function would 
still blithely report that it had successfully formatted the dis¬ 


kette! To ensure that a physical format was actually per¬ 
formed, the BIOS Verify Sectors function must be used. 

After formatting the track, therefore, FormatDiskette() 
calls the VERIFY_TRACK procedure to ensure that the new 
track is readable. The BIOS Verify Sectors function (Int 13h, 
AH=4) simply asks the diskette controller to check that the 
specified sectors can be located and read. Because the argu¬ 
ments and register assignments for both FORMAT_TRACK and 


Listing 1 continued 


DL = physical drive number 
DH = head 

DS:SI -> internal media table 
ES:BX -> workspace for track buffer 

Exit: 

CF = NC, success 

CF = CY, failure 
AL = error code 


Changes: AX CX 


FORMAT JRACK PROC NEAR 

ASSUME CS:CSEG, DS:DGR0UP, ES:NOTHING, SS:DGR0UP 

MOV BYTE PTR [FUNCTION],5 -.Format function # 

JMP SHORT FT_0 ;Jump into nest 


VERIFY_TRACK (Near, Internal) 


Except for the function number, this procedure is identical to the 
FORMAT_TRACK procedure. 



Discover the WHY and HOW of application design 
and development in C. Explore the construction of 
several different applications from start to finish. 
Chapter after chapter you’ll develop your skills 
through in-depth tutorial and detailed code. 



; Changes: AX CX 


VERIFY 

rRACK PROC 

NEAR 



ASSUME CS:CSEG 

, DS:DGR0UP, ES:NOTHING 

SS:DGR0UP 


MOV 

BYTE PTR [FUNCTION],4 

;Verify function # 

FT_0: 






PUSH 

BP 

;Save used registers 


PUSH 

DI 



PUSH 

AX 



MOV 

CL, 1 

;Starting sector 

; Build 

the track buffer for this track (CHRN) 


; Leave 

ES:BX pointing 

to the beginning of the 

track buffer. 


PUSH 

AX 

-.Save passed info 


PUSH 

CX 



PUSH 

DX 

;DH = head 


MOV 

DL,CH 

;Put track in DL 


SUB 

CH.CH 

;CH = 0 


MOV 

CL,AL 

;Number of sectors 


MOV 

DI.CX 

;Point DI 2 bytes 


SHL 

DI, 1 

; less than length 


DEC 

DI 

; of finished buffer 


SHL 

DI.l 



ADD 

DI.BX 

;Point to end of buf 


STD 


;String moves reversed 


MOV 

AL.CL 

;Sector number 


MOV 

AH,2 

;Bytes/sector code=512 

FTJ: 

STOSW 


-.Write sector/code 


DEC 

AL 

;Dec sector number 


XCHG 

AX.DX 

;Swap data 


STOSW 


;Write track/head 


XCHG 

AX.DX 

-.Swap data back 


LOOP 

FTJ 

;Build entire track 


CLD 


;String moves forward 


POP 

DX 

;Restore values 


POP 

CX 



POP 

AX 


; Format or verify the track, depending on the 

function value. 

FT_2A: 

MOV 

DI.AX 

;Save retries 


MOV 

AH,[FUNCTION] 

;Format or verify 


INT 

13H 

; thru BIOS 


JC 

FT 2B 

;NC = success 

; Exit the routine succesfully. 


POP 

AX 

;Restore AX 

FT_EXIT 

POP 

DI 

;Restore registers 


POP 

BP 


RET 
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VERIFY_TRACK are identical, the procedures are nested to 
reduce code size. 

If, for any reason, track 0 on both sides of the diskette 
cannot be formatted and verified successfully, Format- 
Diskette () returns an error value of OAh. Note that this error 
code will be returned even if a more specific error code, such 
as a write protect violation, is returned by the BIOS. If track 0 
is bad, the diskette is unusable by DOS and should be dis¬ 
carded. 


To format the remainder of the diskette, the FORMAT_ TRACK 
and VERIFY_TRACK routines are called once for each track and 
head combination on the diskette. For tracks other than track 
0, the number of retries is reduced to 3. If the format or verify 
operation fails after 3 tries, that section of this diskette is 
deemed unusable and its coordinates are passed to the 
MARK_TRACK_BAD procedure. 

Given a head, track, and sector number, the 
MARK_TRACK_BAD procedure will translate those BIOS 


Listing 1 continued 


FUNCTION was unsuccessful. Retry, then fail. 


FT 26: 


MOV 

BP, AX 

;Save error code (AH) 

SUB 

AH. AH 

;Reset diskette system 

INT 

13H 

; thru BIOS 

CALL 

SET MEDIA 

;Set media type again 

JC 

FT_ERR 


MOV 

AX.DI 

;Get back retries 

DEC 

AH 

;Dec them 

JNZ 

FT 2A 

;NZ = try again 

Exit as a failure. 

MOV 

AX, BP 

•.Retrieve error code 

FT ERR: 



MOV 

AL.AH 

;Error code in AL 

STC 


;Signa1 failure 

POP 

DI 

jDiscard old AX 

JMP 

FTJXIT 


VERIFY TRACK ENDP 



FORMATJRACK ENDP 



MARK_TRACK_BAD (Near, 

Internal) 


Given the C (CH), H (DH), and R 

(always 1) coordinates of the first 


sector to mark bad, mark AL contiguous sectors bad in the FAT. 

Note the following: 

BIOS sector numbers are 1-based 

LSNs (logical sector numbers) are 0-based 

CNs (cluster numbers) are 0-based 


Entry: 

CH = track 

DL = physical driver number 
DH = head 

DS:SI -> media table 
Exit: None 


Changes: None 


MARK TRACK BAD PROC NEAR 

ASSUME CS:CSEG, DS:DGR0UP, ES:NOTHING, SS:DGR0UP 

PUSH AX ;Save used registers 

PUSH BX 

PUSH CX 

PUSH DX 

PUSH DI 

PUSH ES 


Translate CHR coordinates to a 0-based logical sector number. 

LSN = SPT*(NH*C+H)+S-1 

where 

LSN = logical sector number (0-based) 

SPT * sectors per track 

NH = number of heads (always =2) 

C = track (0-based) 

H = head (0-based) 

S = BIOS sector number (1-based) (always =1) 


SUB 

CL,CL 

;CL = 0 

XCHG 

CH.CL 

;CX * Track I 

ADD 

CL,CL 

;*2 sides 

ADD 

CL.DH 

;Acct for odd head 

SUB 

AH, AH 

;AX = sect per track 

MOV 

AL,[Sl+27] 

;Sect per track 

MUL 

CX 

;LSN in DX:AX 

MOV 

CX.AX 

;Save LSN of 1st bad 

Determine the LSN of 

the first data sector. 


FDS = NF*SPF + RDS + 

RS 


MOV 

AX,[SI+25] 

jSectors per FAT 

MUL 

BYTE PTR [SI+19] 

;* copies of FAT 

ADD 

AX,[SI+17] 

;+ reserved sectors 

ADD 

AL,[SI+2] 

;+ root dir sectors 

Subtract the LSN of 

the first data sector from our target LSN. 

This gives the sector number offset from the 

first data sector. 

NEG 

AX 

;Make negative 

ADD 

AX.CX 

;Subtract from LSN 


; Convert DSN to a 0-based cluster number (CN). 


Windows DLLs 

Now you can write your UNIX screen, and communication applications 
under Windows, supporting Microsoft 7.0 and Borland 3.1, or any 
Windows language through the our dll. They support dynamic linked 
library interfaces. Products include object (with dll), source (optional), 
working example programs, and documentation. No run-time. 

CrystalComm for Windows $175 

CrystalComm is a communications library written in C for the Windows 
environment It supports the development of modem or serial port 
communication programs. It includes everything to maintain 
consistency in the Windows environment (foreground or background) 
and includes dll support CrystalComm supports XMODEM, XMODEM 
CRC, YMODEM, YMODEM-G, ZMODEM, KERMIT, and ASCII 
communication protocols through a simple, structured function 
interface. Supports both packet or file calls. KERMIT 8 bit quoting and 
get command. Great examples in C, Turbo Pascal, and Visual Basic. 
Also under DOS for $125. 

Crystal CURSES for Windows $175 

Crystal CURSES for Windows is a UNIX CURSES library for the 
Windows environment If you desire to move your UNIX CURSES 
based application to the Windows environment simply without rewriting 
the screen interface to comply with the Windows GUI, CURSES for 
Windows is the library for you. Crystal CURSES includes support for 
both dll (dynamic linked library). The functionality of CURSES in the 
Windows environment is expanded to include Font and Dialog control. 
Complete UNIX V implementation. Also available under DOS for $125. 
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Listing 1 continued 


MOV 

SUB 

DIV 

BL,[SI+16] 
BH.BH 

BX 

;Sect per cluster 
;Extend to word 

; The first data sector corresponds to cluster number 2. 

; Bias the resulting CN by 2. This is 

the starting cluster number. 

ADD 

AX,2 

;Bias cluster # 

MOV 

DX.AX 

;Starting cluster # 

; Determine how many clusters (NC) we 

need to mark as bad. 

SUB 

AH, AH 

;AH = 0 

MOV 

AL,[SI+27] 

;Sect per track 

INC 

AX 

;Round up 

DIV 

BYTE PTR [SI+16] ;AL=AX/sect per cluster 

SUB 

CH.CH 


MOV 

CL.AL 

;CX = # bad clusters 

; Point ES:DI to FAT buffer. 

MOV 

DI,[SBUFPTR] 


; Beginning with the first CN (in DX), 

mark NC (in CL) clusters bad. 

; Assume a 12-bit fat. 



MTB 1A: 



MOV 

BX.DX 

{Cluster number 

SHL 

BX, 1 

;* 2... 

ADD 

BX.DX 

;-> *3 

SHR 

BX,1 

;\ 2 -> offset 

TEST 

DL.l 

;Even or odd? 

JNZ 

MTB_1B 


OR 

WORD PTR ES:[DI][BX],0FF7H ;Even entry 

JMP 

SHORT MTB 1C 


MTB IB: 



OR 

WORD PTR ES: [DI] [BX],0FF70H ;Odd entry 

MTB 1C: 



INC 

DX 

;Next cluster number 

LOOP 

MTB_1A 


; Return to caller. 

POP 

ES 

{Restore registers 

ASSUME ES:NOTHING 


POP 

DI 


POP 

DX 


POP 

CX 


POP 

BX 


POP 

AX 



RET 

MARK TRACK BAD ENDP 


BIOS_WRITE (Near, Internal) 


This proc automatically Increments sectors, heads, and tracks and 
performs as many writes as required to output the total number of 
sectors requested. It leaves the counters pointing to the next 
available sector. 


Entry: 

AL = total sectors to write 
CL = starting sector 
CH = track 

DL = physical driver number 
DH = head 

DS:SI -> media table 

ES:BX -> workspace for track buffer 

Exit: 

CY = FAIL 
AL = error code 

NC = SUCCESS 

* = coordinates of first sector after write 
CL = starting sector * 

CH = track * 

DL = physical drive number * 

DH = head * 


; Changes: AX CX DX 

BIOS WRITE 

PROC 

NEAR 


ASSUME 

CS:CSEG, DS:DGROUP, 

ES:NOTHING, SS:DGROUP 


PUSH 

BX 

;Save registers 


PUSH 

DI 


; Save the current T: 

H:S coordinates. 


MOV 

[NSECT],AL 

{Save total sectors 


MOV 

[SECT],CL 

{Current sector 


MOV 

[HEAD],DH 

;Head 


MOV 

[TRACK],CH 

;Track 

; Determine how 

many 

sectors can be 

written without having to change 

; heads or tracks. Write either that many or the number of requested. 

; whichever is 

fewer. 



BW 1A: 





MOV 

AH,[SI+27] 

;Sectors per track 


XCHG 

AH.AL 

; in AL 


SUB 

AL.CL 

;Subtract starting sect 


INC 

AL 

{Sectors left this track 


CMP 

AH.AL 

;CMP want to have 


JA 

BW_1B 



MOV 

AL.AH 

;Write AL sectors 

BW IB: 




“ 





This section calculates what the coordiantes of the next free sector 
will be AFTER the write is completed. 


SUB 

[NSECT],AL 

jSubtract # written 

ADD 

CL.AL 

; last used sector 

BW 2A: 



CMP 

CL,[SI+27] 

;CMP sect to max 

JBE 

BW_2B 


SUB 

CL,[SI+27] 

{Subtract sec per track 

XOR 

DH, 1 

{Move to next head 

JNZ 

BW_2A 


INC 

CH 

;Next track 

JMP 

BW 2A 


BW 2B: 



XCHG 

[SECT],CL 

;Current sector 

XCHG 

[HEAD],DH 

{Head 

XCHG 

[TRACK],CH 

;Track 

; Write the indicated 

number of sectors. Advance the buffer pointer. 

MOV 

DI.AX 

;Save sectors to write 

MOV 

AH,3 

{Write sectors 

INT 

13H 

; thru BIOS 

MOV 

AL.AH 

{Possible error in AL 

JC 

BW_EXIT 


PUSH 

DX 

;Save over mult 

MOV 

AX.DI 

{Get sectors to write 

SUB 

AH, AH 

{AH=0 

MUL 

WORD PTR [S1+14] 

{Bytes per sector 

ADD 

BX.AX 

{Advance buffer pointer 

POP 

DX 


Update the registers 

from the pointers. 


MOV 

CL,[SECT] 

{Current sector 

MOV 

DH,[HEAD] 

{Head 

MOV 

CH,[TRACK] 

{Track 

Continue if more sectors need to be written. 

MOV 

AL,[NSECT] 

{Get number left 

OR 

AL.AL 

jO = no more to write 

JNZ 

BW 1A 


CLC 


{Signal success 

Return to caller. 
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coordinates to FAT coordinates and mark the specified num¬ 
ber of sectors as unusable in the FAT. The translation from 
BIOS coordinates to DOS logical sector number (LSN) can be 
expressed as follows: 

LSN = SPT*(NH*C+H)+S-1 

Where SPT is the number of sectors per track, NH is the num¬ 
ber of heads, C is the current track number (0-based), H is the 
current head number (0-based), and S is the sector number 
(1-based). Subtracting the number of non-data sectors from 
the LSN of the first bad sector yields an offset into the data 
area in sectors. From this is calculated the corresponding 
cluster number. 


Marking the entire track bad if an error is detected may 
seem a bit extreme. Indeed, I had originally planned that 
FormatDiskette() would attempt to salvage partial tracks, 
but relented for two reasons. The first was compatibility with 
the DOS FORMAT program, which marks off entire tracks. The 
second, and more compelling, reason was that it seemed un¬ 
economical — most folks will just throw away a diskette with 
bad sectors. 

Logical Format 

Once the physical format is complete, the logical format 
must be impressed on it to create a DOS-compatible disk. As 
mentioned previously, the logical structure requires that you 
create the boot record and the FAT, and initialize the root 
directory. The FAT image that has been built in the buffer is 


Listing 1 continued 


BW EXIT: 


BIOS WRITE 


POP 

POP 

RET 

ENDP 


DI 

BX 


;Restore registers 


BASIC, PASCAL entry point. 


; 1. Arguments are passed by reference. 

; 2. We clean up stack. 


; 3. Per protocol, ES 

is not saved. 


FormatDiskette 

PROC 

FAR 


ASSUME 

CS:CSEG, DS:DGR0UP, 

ES:NOTHING, SS:DGR0UP 


PUSH 

BP 

;Create stack frame 


MOV 

BP.SP 



PUSH 

SI 

;Preserve req'd regs 


PUSH 

DI 



MOV 

BX,[BP+OAH] 

;Point to... 


MOV 

CX,[BX] 

;...media identifier 


MOV 

BX,[BP+OCH] 

jPointer to... 


MOV 

DH,[BX] 

;...drive type 


MOV 

BX,[BP+OEH] 

;Pointer to... 


MOV 

DL,[BX] 

;...drive number 


LES 

DI,DWORD PTR [BP+6] ;Far ptr to buffer 

ASSUME 

ES:NOTHING 



CALL 

FormatDiskette$FAR ;Attempt the format 


POP 

DI 

;Restore registers 


POP 

SI 



POP 

BP 

;Destroy stack frame 


RET 

5*2 

;Discard arguments 

FormatDiskette 

ENDP 



; C entry point. 

• 

; 1. Arguments are passed by value. 


; 2. Caller cleans up 

stack. 


; 3. Per protocol, ES 

is not saved. 


» 

FormatDiskette 

PROC 

FAR 


ASSUME 

CS:CSEG, DS:DGR0UP, 

ES:NOTHING. SS:DGR0UP 


PUSH 

BP 

•.Create stack frame 


MOV 

BP.SP 



PUSH 

SI 

;Preserve registers 


PUSH 

DI 



MOV 

DL,[BP+6] 

;Drive number 

MOV 

DH,[BP+8] 

;Drive type 

MOV 

CX,[BP+OAH] 

;Media identifier 

LES 

DI,DWORD PTR [BP+OCH] 

;Far ptr to buffer 

ES:NOTHING 


CALL 

FormatDisketteSFAR 

;Attempt format 

POP 

DI 

;Restore registers 

POP 

SI 


POP 

RET 

BP 

jDestroy stack frame 


^FormatDiskette ENDP 

CSEG ENDS 

END 


Media information. 

1. Despite what you read in some books, BIOS sectors are 1-based; 
head, track, logical sector, and FAT coordinates are 0-based. 

2. ALL boot, FAT, and root directory sectors are located on track 0. 


BIOS INFORMATION 

360K 

1.2M 

720K 

1.44M 

Max head # (0-based) 

1 

1 

1 

1 

Max track # (0-based) 

39 

(27h) 

79 

(4Fh) 

79 

(4Fh) 

79 

(4Fh) 

Sectors per track 

9 

(9h) 

15 

(Fh) 

9 

(9h) 

18 

(12h) 

Total # sectors 

720 

2400 

1440 

2880 

DOS INFORMATION 

360K 

1.2M 

720K 

1.44M 

Media (format) ID 

FDh 

F9h 

F9h 

FOh 

# Boot sectors 

1 

1 

1 

1 

# Sectors per FAT 

2 

7 

3 

9 

# copies of FAT 

2 

2 

2 

2 

FAT entry type (bits) 

12 

12 

12 

12 

# Sectors in root directory 

7 

14 

7 

14 

# Root directory entries 

112 

224 

112 

224 

# Sectors per cluster 

2 

1 

2 

1 

t Data clusters 

354 

2371 

713 

2847 


(162h) 

(943h) 

(2C9h) 

(BIFh) 


End of File 
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written to the diskette first. After writ¬ 
ing the media identification into the first 
two FAT entries, two copies of the FAT 
are written to the diskette beginning at 
logical sector 1, the first sector after the 
boot record. 

Writing to a diskette through the 
BIOS means keeping track of the head, 
track, and sector coordinates — a task 
that can get quite complex. To simply 
this process, the details of advancing 
across the diskette are hidden in the 
BIOS_URITE procedure. The coordinates 
of the first sector to write, the number 
of sectors, and the source buffer ad¬ 
dress are passed to BIOS_WRITE. The 
procedure automatically increments 
sectors, heads, and tracks and performs 
as many writes as required to output 
the total number of sectors specified. 
When it returns, the registers are set to 
point one past the last sector written, 
in preparation for the next write. 

After both copies of the FAT have 
been written to the disk, one sector of 
the buffer is initialized to contain all 
zeroes. This sector is then written as 
many times as required to initialize the 
root directory. 


Notice to Our 
Subscribers 

Occasionally, Windows/DOS 
Developer's Journal makes its 
mailing list available to vendors 
of products we think our 
readers will find interesting. Cur¬ 
rent subscribers receive free in¬ 
formation in the mail from 
these vendors. 

If you prefer that your name 
not be used in these mailings, 
please let us know. Just copy or 
clip this form and send it with 
your name and address to: 


Windows/DOS 

□ DEVELOPER’S JOURNAL 

1601 W. 23rd. St., Suite 200 
Lawrence, KS 66046-2743 


Listing 2 

DOSSEG 




.Model Medium 




.Stack lOOh 




» 

; Drive types and character equates. 

DRIVE 360 

EQU 

1 


DRIVE 1200 

EQU 

2 


DRIVE 720 

EQU 

3 


DRIVE_1440 

EQU 

4 


CR 

EQU 

13 


LF 

EQU 

10 


> 

; Static data. 

» 

.Data 




MSG1$ 

DB 

"Format which physical 

drive (0,l,etc)?$“ 

MSG2$ 

DB 

CR,LF,LF,"Type 1: 360k 

5.25-inch 40 tracks" 


DB 

CR.LF, “Type 2: 1.2M 

5.25-inch 80 tracks" 


DB 

CR.LF, "Type 3: 720k 

3.5-inch 80 tracks" 


DB 

CR.LF, "Type 4: 1.4M 

3.5-inch 80 tracks" 


DB 

CR.LF, “Drive is what type?$“ 

MSG3$ 

DB 

CR.LF,LF,"1 = 360k" 



DB 

CR.LF, “2 = 1.2M" 



DB 

CR.LF, "3 = 720k“ 



DB 

CR.LF, "4 = 1.4M" 



DB 

CR.LF, "Format to what capacity?$" 

MSG4$ 

DB 

CR.LF,LF,"Format returned " 

RESULT 

DB 

"xxh\CR,LF,"$" 


CAPACITY 

DW 

360,1200,720,1440 


; Uninitialized 

data. 



.Data? 




BUFFER 

DB 

4680 DUP (?) 

;Largest buffer 

» 

; Executable code. 

> 

.Code 




EXTRN 

FormatD 

skette$FAR:FAR 


MAIN 

PR0C 




MOV 

BX.DGR0UP 

;Point DS 


MOV 

DS.BX 

; to data segment 


MOV 

ES.BX 

;Point ES:DI 


MOV 

DI,OFFSET BUFFER 

; to buffer 

> 

; Solicit format details. 

> 

MOV 

AH,9 

•.Display string 


MOV 

DX,OFFSET MSG1$ 

;Ask what drive 


INT 

21H 

; thru DOS 


MOV 

AH, 1 

;Char input with echo 


INT 

21H 

; thru DOS 
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Listing 2 

continued 



MOV 

CL.AL 

;Save drive 


MOV 

AH,9 

;Display string 


MOV 

DX,OFFSET MSG2$ 

;Ask drive type 


I NT 

21H 

; thru DOS 


MOV 

AH, 1 

;Char input with echo 


I NT 

21H 

; thru DOS 


MOV 

CH.AL 

;Save type 


MOV 

AH,9 

;Display string 


MOV 

DX,OFFSET MSG3$ 

;Ask capacity 


I NT 

21H 

; thru DOS 


MOV 

AH, 1 

iChar input with echo 


INT 

21H 

; thru DOS 


SUB 

AL.31H 

[Convert to digit 


CBM 


[Convert to word 


ADD 

AX, AX 

[Double for indexing 


MOV 

BX.AX 

[Put in base register 


MOV 

AX,[CAPACITY][BX] 

[Then put capacity code 


XCHG 

AX.CX 

; in CX 


SUB 

AX.3030H 

[Convert to numbers 


MOV 

DX, AX 

[Put into DX 


CALL 

FormatDiskettesFAR 

[Format a diskette 

; Convert the 

return 

code to ASCII and display. 



MOV 

CL,4 

[Shift count 


MOV 

CH.30H 

[ASCII blank 


MOV 

AH.AL 

[Save number 


SHR 

AL.CL 

[Get high-order digit 


CMP 

AL.OAH 

;0-9 or A-F? 


JB 

M_1 



ADD 

AL,7 

[Offset for A-F 

M 1: 





ADD 

AL.CH 

[Make ASCII 


AND 

AH.OFH 

[Get low-order digit 


CMP 

AH.OAH 

;0-9 or A-F? 


JB 

M_2 



ADD 

AH,7 

[Offset for A-F 

M 2: 





ADD 

AH.CH 

[Make ASCII 


MOV 

WORD PTR [RESULT],AX 

[Put into message 


MOV 

AH,9 

[Display string 


MOV 

DX,OFFSET MSG4S 

[Report result 


INT 

21H 

; thru DOS 


MOV 

AH.4CH 

[Terminate program 


INT 

21H 

i thru DOS 

MAIN 

ENDP 




END 

MAIN 


; End of File 





Universal 
Printer 
Driver 

Would Text and Graphic 
Printer support for over 
750 Printers (including 
PostScript) give you a 
competitive edge? 

By including SLATE, you can print 
both Text and Graphics on over 750 
printers (including PostScript, 
LaserJet III and the new Epson 
scalable font printers). 
Immediately! Painlessly! 

You can use SLATE in your product 
with no royalties. 

SLATE gets you out of the printer 
support business. Forever! 

Make your product more functional 
and competitive by using SLATE'S 
advanced text features: 

• Support multiple printers on the same 

system. 

• Output to parallel printers, serial printers, 

DOS files/devices, DOS print spooler, 

.and Novell network printers. 

• Include end user's soft fonts. 

• Support cartridge fonts. 

• Support proportional fonts 

• Support scalable font printers. 

• Set exact print positions. 

• Color printing 

• Kerning, leading, overstrike, underlining, 

and strike through. 

• Automatic character set conversion. 

SLATE with Graphics adds advanced 
graphic printing features: 

• Print images from the screen, PCX or TIFF 

files, or custom image systems. 

• Scale and Rotate the printed image. 

• Print grey scale and color images. 

• Intermix text and graphics. 

SLATE is a set of C or Basic libraries 
with over 170 text printing functions, 

a Database of over 750 printers, 
and End User configuration and 
testing programs. 

SLATE with Graphics adds over 60 
graphic printing functions. 

Call now for a complete developer's 
information kit. Order SLATE for 
only $299 or SLATE with Graphics 
for $448 with our risk free, 30 day 
return policy. 


We accept Visa, MasterCard, COD'S or PO's 
from qualified companies. Source code, 
maintenance, and site licenses are available. 


800 - 346-3938 

The 

PO Box 26195 

Symmetry 

Columbus. OH 43226 
614-431-2667 

Group 

FAX 614-431-5734 


SLATE 
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The boot record is then built in the 
buffer. First, the boot record signature 
AA55h is placed at the end of the sec¬ 
tor. Next, the BIOS Parameter Block is 
copied from the media table to the 
beginning of the sector. Finally, the 
bootstrap routine is copied to offset 30h 
within the sector image. When com¬ 
plete, the boot record is written to head 
0, track o, sector 1 of the diskette. 
FormatDiskette() then restores the disk 
base to its original condition and returns 
the result code to the calling procedure. 

Conclusion 

The FormatDiskette() function per¬ 
forms a basic physical format, creates a 
DOS-compatible logical structure, and 
marks off bad areas of a diskette 
using the BIOS diskette functions. It 
also demonstrates the techniques 
required to create special diskette 
formats and load custom bootstrap 
programs. For a relatively small price 
(less than 2Kb of code), Format- 
Diskette () can give any application 
the ability to format diskettes when 
required, increasing the application's 
versatility and effectiveness. □ 



Listing 3 


DEFINT A-Z 

Declare Function FormatDiskette%(DrvNum%,DrvType%,Media%,SEG Buf%) 

DIM Buf% (2340) '4680 bytes 

Input "Format which physical drive”;DrvNum% 

Print 

Print "Type 1: 360k 5.25-inch 40 tracks" 

Print "Type 2: 1.2M 5.25-inch 80 tracks" 

Print "Type 3: 720k 3.5-inch 80 tracks" 

Print "Type 4: 1.4M 3.5-inch 80 tracks" 

Input "Drive is what type";DrvType% 

Print 

Print " 360 = 360k" 

Print “1200 = 1.2M" 

Print " 720 = 720k" 

Print "1440 = 1.4M" 

Input “Format to what capacity'';Media% 

Result% = FormatDiskette%(DrvNum%,DrvType%,Media%,SEG Buf%(0)) 
Print 

IF (Result%=0) THEN 
Print "Format was successful." 

ELSE 

Print "Format failed. Result = Result% 

ENDIF 


Listing 4 


extern int FormatDiskette (int,int,int,char far *) ; 

main() ( 

int DrvNum ; 

int DrvType ; 

int Media ; 

int Result ; 

static char Buf[4680] ; 

printf ("Format which physical drive: ") ; 
scanf ("%d",&DrvNum) ; 

printf ("\nType 1: 360k 5.25-inch 40 tracksV) ; 
printf ("Type 2: 1.2M 5.25-inch 80 tracks\n“) ; 

printf (“Type 3: 720k 3.5-inch 80 tracks\n") ; 

printf ("Type 4: 1.4M 3.5-inch 80 tracks\n") ; 

printf ("Drive is what type: “) ; 
scanf ("%d",&DrvType) ; 

printf ("\n 360 = 360k\n“) ; 

printf ("1200 = 1.2M\n") ; 

printf (" 720 = 720k\n") ; 

printf ("1440 = 1.4M\n") ; 

printf ("Format to what capacity: ") ; 
scanf ("%d“,&Media) ; 

Result = FormatDiskette(DrvNum,DrvType,Media,(char far *) Buf) ; 
Printf ("\nFormatDiskette() returned %d",Result) ; 

} 

/* End of File */ 
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Checking for 
Debug Information 

Matt Pietrek 

In the last-minute rush to get a product out the door, mistakes get made. In my 
experience, one of the most common and embarrassing of these is accidently ship¬ 
ping debugging information with your product. In this article, I present a utility, 
dbginfo.exe, that can help you quickly check for this situation, and thus avoid this 
particular embarrassment. 

Inadvertently supplying debugging information with your program is undesirable 
for several reasons. First, debugging information is a fairly complete representation of 
your program, in that it contains your function and variable names, as well as the 
formats of your data structures. Someone familiar with the format of your debug 
information can use it to greatly speed up the process of reverse engineering. For 

instance, much of the information in Undocumented 
Windows was obtained by examining the CodeView 
information supplied with the debugging DLLs in 
the Microsoft Windows SDK (for more on the format 
of the debug information, see the sidebar). 

Second, debug information can significantly add 
to the file size of the . exe or DLL. In my experience 
with Borland and Microsoft debugging formats, they 
typically double the size of the file for a non-trivial 
program. When you are trying to squeeze your 
product into the fewest possible disks for distribu¬ 
tion, debug information can be a very significant 
dead weight. 


Matt Pietrek is a developer at a large California tools 
vendor. He specializes in debuggers and file brows¬ 
ing/conversion utilities. He is a co-author of the book 
Undocumented Windows. Matthew lives with his 
wife, April, and their two dachshunds, Theodore and 
Gunther, near the beach. 
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Last, leaving debug information in a shipping program just 
plain looks unprofessional. If the programmer did not take the 
time to implement proper build procedures, are you going to 
have confidence in the code itself? 

A related issue arises if your product consists of or includes 
.lib or .obj files. Debug information is produced by the com¬ 
piler and stored in .obj files, along with the code and data 
segments. During the link phase, debug information from the 
various . obj files is combined to form the debug information 
in the executable file. Although dbginfo does not check for 
debug information in .obj or .lib files, the same caveats 
described earlier apply. In addition, the Borland C/C++ com¬ 
pilers by default produce "autodependency” information that 
can also add to the size of your .obj and .lib files. If you 


Looking at the Debug Info 

The two most common formats for debugging infor¬ 
mation on the PC are those used for Borland's Turbo 
Debugger and Microsoft CodeView. The format for the 
debug info in Borland .obj and executable files can be 
found in the Borland Open Architecture Handbook. The 
Microsoft CodeView executable format is described in 
the Microsoft C Developer's Toolkit Reference (Microsoft, 
1990, Part No. 18161). 

If you want to examine the debug information in a 
particular executable file, TDUMP.EXE (a tool written by 
the author and included with the Borland compilers) 
can display both Turbo Debugger and CodeView style 
debug information. In addition, TDUMP can display the 
Borland debug information that's included in .obj/.lib 
files. 

If the sheer volume of information from TDUMP 
overwhelms you, you can narrow down the amount of 
information provided by using some command line 
switches. 

With an executable file, to skip over the display of 
the executable information and only display the debug 
info, use the -ex switch. To see the Borland debug in¬ 
formation in its "raw” tabular format, use the -v 
switch. For example: 

TDUMP -ex -v myfile.exe 

For Borland .obj files, 

TDUMP -oicoment filename.obj 

will eliminate much of the information not related to 
debug information and autodependencies. For .obj files 
with CodeView information, try 

TDUMP -oisegdef filename.obj 

If you see segments that have names starting with 
“$$" (for instance "$$TYPES"), then the .obj file contains 
CodeView style information. □ 


intend to ship your .obj or . lib files, you can use Borland’s 
-x option to suppress generation of this information. The 
sidebar describes how to examine .obj and . lib files in more 
detail. 

Finding CV Debug Information 

Borland and Microsoft format debug information differently, 
so you have to perform two checks. Luckily, in both cases the 
debugging information can be found at the end of the ex¬ 
ecutable file. 

As Figure 1 shows, the Microsoft CodeView debugging in¬ 
formation is relatively easy to find. For DOS, Windows, and 
OS/2 executables, the last eight bytes of the CodeView infor¬ 
mation contain three things: 

• A 2-byte 'NB' signature. 

• A 2-byte version number 

• The length of the debug information (an unsigned long). 

To check for CodeView information, first read the last eight 

bytes of the file to verify that it starts with “NB.” If that signa¬ 
ture exists, then read the beginning of the debug information 
and verify that it also starts with "NB". To find the start of the 
debug information, seek backwards from the end of the file 
by the number of bytes given in the length field in the last 
four bytes of the file. 

Finding TD Debug Information 

The check for CodeView debugging information is the same 
whether you are examining a DOS executable or a Windows 
executable. Borland’s debugging information, however, gets 
stored differently in Windows executables than in DOS ex¬ 
ecutables. 

When producing a Windows executable, both TLINK and 
Turbo Pascal for Windows produce a CodeView "shell" around 
the Turbo Debugger information. Because of this, the previous 
algorithm for detecting CodeView debugging information will 
work the same for a Borland Windows executable that con¬ 
tains debugging information. You should note, however, that 
the debugging information between the two “NB" signatures is 
not CodeView information, but is, instead, Turbo Debugger in¬ 
formation. This shell around the Turbo Debugger information is 
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Listing 1 oldexe.h 



// . ============ 

// DBGINFO by Matt 
// File: OLDEXE.H 

typedef struct 

Pietrek, 1992 



{ 

I* DOS 

'old' EXE Header */ 



unsigned char 

signature[2] ; 

1* EXE File validity mark 

*/ 


unsigned short 

lastsector; 

/* length MOD 512 

*/ 


unsigned short 

numblocks; 

/* number of whole 512 bytes 

*/ 


unsigned short 

reloc size; 

/* Relocation table size 

*/ 


unsigned short 

header size; 

/* Size of header record 

*/ 


unsigned short 

min mem; 

/* Minimum Load Memory 

*/ 


unsigned short 

max mem; 

/* Maximum Load Memory 

*/ 


unsigned short 

stack seg; 

/* Stack segment segment 

*/ 


unsigned short 

stack off; 

/* Stack segment offset 

*/ 


unsigned short 

checksum; 

/* File load checksum 

*/ 


unsigned short 

code off; 

/* Entry point offset 

*/ 


unsigned short 

code seg; 

/* Entry point segment 

*/ 


unsigned short 

reloc offset; 

/* Offset to relocation table*/ 

unsigned short 
) OLDEXEHEADER; 

/* End of File */ 

overlayjiumber; 

/* Overlay Number 

*/ 


necessary because Microsoft's resource 
compiler ( rc.exe) discards anything at 
the end of an executable file that it 
does not recognize as CodeView infor¬ 
mation. The actual Turbo Debugger in¬ 
formation starts 16 bytes past the first 
"NB” signature in the file. The start of 
the Turbo Debugger information can be 
identified by the two-byte sequence: 

FBh, 52h. 

Although a single check suffices to 
detect debugging information in 
Microsoft DOS and Windows ex¬ 
ecutables and in Borland Windows ex¬ 
ecutables, you need a different algo¬ 
rithm to detect debugging information 
in Borland DOS executables. The algo¬ 
rithm is to find the end of the ex¬ 
ecutable portion of the file, and then 
look for the FBh, 52h signature. For a 
non-overlaid DOS executable, the end of 
the file is found by using the fields in 
the “Old EXE” header. The format of the header is given in 
oldexe.h (Listing 1), and is described in a number of books, 
including the MS-DOS Encyclopedia. If the executable contains 
overlays, you have to first find the end of the “DOS ex¬ 
ecutable" portion of the file, and then skip over the overlay 
information section before looking for the debug information 


signature. The format of the Borland VROOM overlays section 
is given in Borland's Open Architecture Handbook. 

The dbginfo Code 

The code for dbginfo is in oldexe.h (Listing 1) and dbgin¬ 
fo. c (Listing 2). My goal was to let you quickly search for 
debug information in any set of executable files. You might 


windowsiDOS Code Listings 
Available via UUCPI 


The listings for all code in each issue of Win- 
dows/DOS Developer’s Journal are now being archived 
in machine-readable form by UUNET Technologies, Inc. 
Each archive file has a pathname of the form 


uunet!~/published/windowsdos/19YY/monYY.zip 


where mon is the first three letters of the month (jan, 
feb, etc.) and YY is the last two digits of the year (e.g., 
92). To uncompress the archives, use unzip filename. 
See the file called filename.txt, included in each ar¬ 
chive, for an explanation of the archive’s contents. This 
directory is also accessible via anonymous FTP from 


ftp.uu.net. 

You may download these archive files via uucp 
even if you do not have a UUNET account: have your 
uucp program call 1-900-GOT-SRCS and use the login 
name uucp, no password. Callers will be charged a 
nominal fee for connect time (currently 50 cents per 
minute). The modems are mostly Telebit T3000's, 
which support most of the faster communication 


protocols. 

Code for each issue is also available on diskette 
from R&D Publications at $5.00 per disk (call 913-841- 
1631 for information). 

publications, inc. 


G!L 2. 


Graphical Instrument Librar 

The universal library for building 
fast graphical displays for data 
acquisition and control. 




Rich set of instruments includes: 

Dial gauges, bar gauges, thermometers, seven-segment 
displays, strip-charts, annunciators, alarms, signal 
conditioning, timing, PID control and more! 

All instruments are fully scalable. Virtual coordinates 
allow programs to run unmodified on over 27 video modes! 
Works with any data acquisition hardware, 
even serial-based systems! 

One version supports Turbo C, Microsoft C, QuickC. 
QuickBASIC, Turbo Pascal and others available soon. 


For a free demo, call 

( 404 ) 352-4788 

1920 Moores Mill Rd., Atlanta, GA 30318 


Advanced 

Design 

Solutions 
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Listing 2 dbginfo.c 

//=„.. 

/* DOS Loader will pay attention to. */ 

// DBGINFO by Matt Pietrek, 1992 


// File: DBGINFO.C 

endOfExelmage ■ oldheader->numblocks * 512L; 


if ( oldheader->lastsector ) 

#include <stdio.h> 

endOfExelmage -= (512 - oldheader->lastsector); 

#include <stdlib.h> 


finclude <dos.h> 

if ( endOfExelmage >= fileLen ) 

finclude <dir.h> 

return 0; 

#include “oldexe.h" 



/* seek to the end of the Exe image portion, */ 

fdefine CV SIGNATURE 0x424E /* 'NB' */ 

/* and read in the signature word . */ 

Idefine TD SIGNATURE 0x52FB 


#define BOR OVERLAY SIGNATURE1 0x4246L /* 'FB' */ 

fseek(exefile, endOfExelmage, SEEK SET); 

#define B0R_0VERLAY_SIGNATURE2 0x564FL /* 'OV' */ 

fread(&signature, sizeof(signature), 1, exefile); 

char HelpString[] = 

/* Is this a Borland overlay file??? If so, */ 

"DBGINFO Version 1.0 Copyright (c) 1992 Matt Pietrek\n\n" 

/* we must get past the overlay portion before */ 

"Syntax: DBGINFO <filespec>\n\n" 

/* we can look for the TD debug info signature */ 

"Lists all files for a given file specification that contain Bor- 


land\n" 

if ( signature == BOR OVERLAY SIGNATURE1 ) 

"Turbo Debugger or Microsoft CodeView information.\n"; 

{ 


fread(&signature, sizeof(signature), 1, exefile); 

/* Returns 1 if the file contains the 'NB' signatures used by */ 

if ( signature != BOR OVERLAY SIGNATURE2 ) 

/* CV, CVW, and TDW, 0 if not */ 

return 0; 

int HasCodeViewStyleInfo(FILE *exefile) 

/* Find out how long the overlay info is */ 

1 

unsigned short signature=0; 

fseek(exefile, endOfExeImage+4, SEEK SET); 

unsigned long debuglnfoLen; 

fread(&overlayLen, sizeof(overlayLen), 1, exefile); 

/* Seek 8 bytes from the end of the file, */ 

endOfExelmage += (overlayLen+16); 

/* and look for the 'NB' signature */ 



if ( endOfExelmage >= fileLen ) 

fseek(exefile, -8, SEEK END); 

return 0; 

fread(&signature, sizeof(signature), 1, exefile); 



/* Seek past the end of the overlay info, */ 

if ( signature != CV SIGNATURE ) 

/* and read in another signature word, in */ 

return 0; 

/* preparation for looking for debug info */ 

/* Read in the length of the debug information */ 

fseek(exefile, endOfExelmage, SEEK SET); 


fread(&signature, sizeof(signature), 1, exefile); 

fseek(exefile, -4, SEEK END); 

) 

fread(&debugInfoLen, sizeof(debuglnfoLen), 1, exefile); 



return (signature == TD SIGNATURE) ? 1 : 0; 

/* Seek to the start of the debug info, and */ 

) 

/* look for the corresponding 'NB' signature */ 


signature = 0; 

/* Opens a file, and verifies that it is some kind of .EXE by */ 

fseek(exefile, O-debuglnfoLen, SEEK END); 

/* looking for the 'old' EXE signature. It then calls the */ 

fread(&signature, sizeof(signature), 1, exefile); 

/* above routines to see if the file contains debug info. */ 

return (signature == CV SIGNATURE) ? 1 : 0; 

i 

/ -------- I 

void CheckForDebugInfo(char *filename) 

/ 

/ 

i 

FILE ‘exefile; 

/*.*/ 

OLDEXEHEADER oldheader; 

/* Returns 1 if the file contains debug information for the DOS */ 


/* version of Turbo Debugger, 0 otherwise. */ 

if ( ! (exefile = fopen(filename, “rb"))) 

/*.*/ 

return; 

int HasTDStyleInfo(FILE *exefile, OLDEXEHEADER *oldheader) 


( 

/* Read in the 'old' style DOS EXE header, and */ 

unsigned long endOfExelmage, fileLen, overlayLen; 

/* verify that it's an .EXE by looking for ' MZ ' */ 

unsigned short signatured; 



fread(&oldheader, sizeof(oldheader), 1, exefile); 

/* Return failure if the file is a Windows or OS/2 file */ 



if ( (oldheader.signature[0] != ' M ') || 

if ( oldheader->reloc offset == 0x40 ) 

(oldheader.signature[l] != ‘Z') ) 

return 0; 

{ 


fclose(exefile); 

/* find out how long the file is */ 

return; 

fseek(exefile, 0, SEEK END); 

) 

fileLen = ftel1(exefile); 

/* If either of the 2 functions return 1, */ 


/* print out the full pathname of the file */ 

/* Calculate how much of the file the */ 
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also find it handy to use in your makefile when doing a 
“production build.” With a little extra work, you could modify 
it to remove the debug information from the end of the file, a 
la Borland's TDSTRIP. 

A couple of sections of the code in dbginfo.c are worth 
looking at in a little detail. First, the IterateThroughFiles() 
function allows you to specify any legal file specification on 
the command line, including wildcards. For instance, you could 
type: 


dbginfo c:\myproj\output\*.* 

The wildcards are expanded by using _dos_findfirst() and 
_dos_findnext(). dbginfo will display the complete file and 
path name of any executables that contain either Borland or 
Microsoft style debug information. 

To allow you to use wildcards but not slow down the 
search, the CheckForDebugInfo() function first verifies that 
the file passed to it is an executable file. Because all ex¬ 
ecutable files contain an “Old EXE" header, the potential “Old 
EXE” header is read in, and the first two bytes are checked for 
the “MZ” signature. If the file is not an executable file of some 
sort, the function returns immediately. 

Of the four most common permutations of executables and 
debug formats (Borland/Microsoft, DOS/Windows), three can be 
found by looking for the CodeView signatures. Naturally, then, 
dbginfo first looks for debug information containing the Code¬ 
View signatures. If it does not find the CodeView signatures, it 
checks for the 1 remaining case (a Borland DOS executable). 


IT WORKS!! 
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Listing 2 continued 


if ( HasCodeViewStylelnfo(exefile) || 

HasTDStyleInfo(exefile, Aoldheader) ) 
pnntf("%s\n“, filename); 

fclose(exefile); 

) 


/* . */ 

/* Takes the filespec given on the command line, and uses */ 
/* _dos_findfirst/_dos_findnext to iterate through the files. */ 
/* For each file, CheckForOebugInfo() is called to look for */ 
/* debug information in the file. */ 
/*.*/ 


void IterateThroughFiles(char *filespec) 

I 

char ful 1PathName[_MAX_PATH]; 
char drive[_MAX_DRIVE], dir[_MAX_DIR]; 
char fi1e[_MAX_FNAME], ext[_MAX_EXT]; 
struct find_t ffblk; 
int done; 

/* Break the passed in filespec into it's component */ 

/* parts, so that we can construct a full path name */ 
/* for each file found by _dos_findfirst/next. */ 

_fnsplit(filespec, drive, dir, file, ext); 
sprintf(fullPathName,“%s%s%s%s", drive, dir, file, ext); 


/* Begin iterating through all of the files. */ 
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The HasTDStylelnfo() function examines the “Old EXE” 
header to see if the file is really an OS/2 or Windows ex¬ 
ecutable. If so, it returns immediately, since the debug infor¬ 
mation for those types of files would already have been found 
in the HasCodeViewStyleInfo() function. The one tricky thing 
that HasTDStylel nfo () does is skip over a VROOM overlay 
section if one is present. At several points, HasTDStyleInfo() 
will return FALSE if the end of the executable section coin¬ 
cides with the end of the entire file. 

Summary 

Testing for debugging information before shipping a pro¬ 
gram should be mandatory procedure for every developer: 
dbginfo allows you to do this quickly and easily. Ifyou apply 
the techniques described here, you will find yourself in a 
much better position to avoid the pitfalls of a hasty rollout. 

References 

Ray Duncan, ed. The MS-DOS Encyclopedia. Redmond, WA: 
Microsoft Press, 1988 (ISBN 1-55615-174-8, $69.95). 

Open Architecture Handbook: The Borland Developer's Tech¬ 
nical Guide, 1991, Part # 14MN-RCH01-01. Contact Borland at 
(800) 331-0877 ( $49.95). □ 


Listing 2 continued 


done = _dos_findfirst(ful1PathName, _A_N0RMAL, iffblk); 
while ( Idone ) 

{ 

sprintf(fullPathName,"%s%s%s“, drive, dir, ffblk.name); 
CheckForDebugInfo(ful1PathName); 
done = _dos findnext(&ffblk); 

} 


int main(int argc, char *argv[]) 

{ 

if ( argc 1=2 ) 

( 

printf(HelpString); 

exit(l); 

I 

IterateThroughFiles(argv[l]); 
return 0; 

} 

/* End of File */ 
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New Products 

Industry-Related News & Announcements 


Toolkit Gives Windows Programs PCX Smarts 


Genus Microprogramming is now shipping the PCX 
Toolkit for Windows vl.O. The new toolkit lets Windows 
programs manipulate PCX bitmapped graphics, and supports 
any language that can call DLL routines. 

The PCX Toolkit for Windows is the Windows version of 
Genus' PCX Programmer's Toolkit for DOS. Its more than 30 
functions include: bitmap and DIB support, display functions, 
ability to save PCX images, palette manipulation, clipboard 
support, and the ability to store PCX files as resources. The 


toolkit also includes pcxShow, an image display and capture 
utility. 

The package is compatible with Windows 3.1 and in¬ 
cludes example programs in a variety of languages. The PCX 
Toolkit for Windows costs $249, or $599 with source code. 
For more information, contact Genus Microprogramming, 
2900 Wilcrest, Suite 145, Houston, TX 77042-3355, (800) 
227-0918 or (713) 870-0737. 


Viewpoint Library Eases C++ Graphics Programming 


The Viewpoint C++ Graphics Library is a package of 
graphics and drawing tools for C++ programmers who want 
to create graphical DOS applications. The routines provide 
both high-level and low-level graphics operations. Mouse 
support includes the ability to queue mouse events, fully 
definable mouse shapes, full-color mouse cursors, and con¬ 
trol over event handling. A number of cursors can be 
specified and active in certain screen areas or under specific 
conditions. The mouse can use any video page, even when 
page flipping. 


The library is compatible with C++ compilers from 
Microsoft, Borland, Zortech, and Comeau Computing. The 
library supports a variety of video cards including 
monochrome, EGA, VGA, MCGA (256 colors), SVGA (various 
boards, plus VESA), Hi-color cards, and S3 Inc’s GUI Ac¬ 
celerator. 

The Viewpoint C++ Graphics Library costs $225, and in¬ 
cludes complete source code and a 60-day, money-back 
guarantee. For more information, contact Dlugosz Software, 
P.O. Box 867506, Plano, TX 75086, (214) 618-2023; BBS 
(214) 618-8642; CIS 70007,4657. 


Liant Produces Major C++/Views Update 

C++/Views v2.0 is a new release of Liant's C++ class 
library for GUI programming. C++/Views allows programmers 
to develop applications portable to Microsoft Windows, OS/2 
Presentation Manager, and UNIX/Motif without having to 
spend time learning each of the three windowing environ¬ 
ments, and still produce applications that conform to the 
exact look and feel of each environment. Besides platform in¬ 
dependence, C++/Views also offers compiler independence; 
under Windows, the package is compatible with Borland C++ 
v3.0, Zortech C++ v3.0, and Microsoft C++ v7.0. 

This version includes a re-engineered Notifier class that 
gives users full control of resource-based dialogs and full MDI 
support via the MdiClient, MdiAppView, and MdiView classes. 
Programmers can also encapsulate and dispatch any event 
from the Notifier class to any Window object. New DdeClient 


and DdeServer classes support DDE, allowing programmers 
to pass C++ objects between Windows applications. 
C++/Views now also supports DLLs. 

The package includes C++/Browse, a complete integrated 
C++ class browser and source code development tool. 
C++/Browse provides both high-level views of your class 
hierarchy and access to detailed views, including individual 
functions. C++ Browse also automates the mechanics of 
building an application, including building make files. 

Liant C++/Views costs $495 for Microsoft Windows ($99 
for an upgrade), $995 for OS/2 Presentation Manager ($499 
for an upgrade), or $1,495 for UNIX/Motif ($749 for an 
upgrade). For more information, contact Liant Software Cor¬ 
poration, 959 Concord Street, Framingham, MA 01701- 
4613, (508) 872-8700; FAX (508) 626-2221. 


October 1992 


Windows/DOS Developer's Journal — Page 71 











Realt/me BIOS Comes Royalty-Free 

General Software has announced the Embedded BIOS 
Adaptation Kit, a full source code BIOS that embedded sys¬ 
tem developers can customize for their own embedded 
hardware. Embedded BIOS comes with over 15,000 lines of 
assembly language source code, over 30 configuration op¬ 
tions, a set of ROM building utilities, a ROM disk BIOS exten¬ 
sion module, remote disk software, and General Software's 
BIOS-aware debugger. 

The new BIOS provides special support for on-chip 
peripherals of the 80186 family, including programming chip 
selects, on-chip timers, on-chip interrupt controller, and 


Nu-Mega Enhances Soft-ICE/W 

Nu-Mega Technologies, Inc. is now shipping Soft-ICE/W 
vl.l, a debugger that specializes in enhanced-mode Win¬ 
dows debugging. Soft-ICE/W provides source-level access to 
any Windows application as well as lower system-level 
debugging capabilities. The debugger provides access to in¬ 
ternal Windows structures and symbols and can be used to 
debug VxDS, DOS boxes, and Windows drivers. Soft-ICE/W 
uses the 386/486 architecture to provide hardware-style 
breakpoints. You can set breakpoints on memory locations, 
memory ranges, I/O port accesses and interrupts. 

In addition to Windows 3.1 and MSC v7.0 support, the 
new debugging features include .sym file support, automatic 
symbol table switching, loading exported symbols from DLLs, 


other functions. Embedded BIOS can be configured to a 
standard AT or a hybrid platform employing both on-chip 
and external peripherals. Embedded BIOS supports AT-com- 
patible BIOS functions in a realtime environment, with an in¬ 
terrupt latency of less than 10 instructions. The BIOS is also 
fully reentrant when used with General Software's Em¬ 
bedded DOS operating system. 

The Embedded BIOS Adaptation Kit costs $350 and is the 
only royalty-free BIOS commercially available. For more infor¬ 
mation, contact General Software Inc., P.O. Box 2571, Red¬ 
mond, WA 98073, (206) 391-4285; FAX (206) 746-4655. 


displaying Window handles, Window classes, and VM infor¬ 
mation. Soft-ICE/W can debug any Windows component at 
source level, including 32-bit and 16-bit Windows applica¬ 
tions, Windows device drivers, Windows virtual device 
drivers (VxDS), DOS applications, TSRs, and DOS loadable 
device drivers. You can debug these components separately 
or as multiple components concurrently. 

Soft-ICE/W requires at least an 80386 processor with a 
minimum of 256Kb of extended memory, and costs $386. 
For more information, contact Nu-Mega Technologies, Inc., 
P.O. Box 7780, Nashua, NH 03060-7780, (603) 889-2386; 
FAX (603) 889-1135. 


Richter’s Voyeur Spawns Tool Suite 

Jeffrey M. Ricther, author of Windows 3.- A Developer's 
Guide, included a utility with his book called Voyeur for in¬ 
specting window information such as style bits. He has since 
expanded this tool and added others and now MicroQuill 
Software Publishing, Inc., has signed an exclusive agreement 
to publish the suite, called DeMystifiers. 

DeMystifiers consists of five independent tools: Colonel 
(memory and heap inspection), Voyeur (window message 


and attribute inspection), Mechanic (GDI device inspection 
and manipulation), Ecologist (displaying static and dynamic 
environment information), and Blowup (allowing pixel-level 
inspection of any part of the display). 

DeMystifiers costs $129. For more information, contact 
MicroQuill, 4900 25th Avenue NE, #206, Seott/e, WA 
98105, (206) 525-8218; FAX (206) 525-8309. 


3-D CAD Program Includes C++ Source 

Napier Graphics has released NAPCAD/3D, a 3-D com¬ 
puter-aided design program for Windows that includes C++ 
source. The package supports lines, cubic spline curves, 
circles, polygons, cones, cylinders, spheres, 3D surface 
patches, sweeps, and extrusions. Users can have up to three 
viewports active simultaneously, to view a model from dif¬ 
ferent angles and sizes. Users can also define their own fonts 
and symbol libraries, where symbol size and angle are deter¬ 
mined upon placement. Models can be shaded using up to 
eight light sources, and the package supports up to 256 
layers. The package can print drawings to any Windows 
graphics printer. 


NAPCAD/3D is written with Borland's C++ and Object¬ 
Windows (versions 3.0 and 3.1 are supported). The source 
code is commented to ease customization. There are no 
royalties for distributing programs that use portions of the 
NAPCAD/3D code, but some restrictions apply. 

The package requires a mouse and Napier recommends 
a math coprocessor. NAPCAD/3D costs $99 and includes a 30- 
day, money-back guarantee. For more information, contact 
Napier Graphics, 3212 20th SE, Auburn, WA 98002, (800) 
800-1961. 


Loose Data Binder Provides Object Persistence 


Loose Data Binder (LDB) vl.7 is the latest version of PSW's 
C++ class library. LDP provides strong type checking with or 
without C++ templates and includes an unconventional per¬ 
sistent container class with a hybrid stack, queue, dequeue, 
list, array interface, and built-in sort, search, and iterator 
functions in one flat class. 

An LDB network of containers and elements can be 
streamed using only one insertion/extraction operation. You 


can use LDB as a kernel (typically consuming less than 10Kb 
of memory) for rolling your own framework/CASE tool. 

The package includes source code and a manual with 
more than 100 pages. Loose Data Binder vl.7 costs $60 and 
is royalty free. For more information, contact PS W/Power 
Software, P.O. Box 10072, McLeon, VA 22102-8072, (703) 
759-3838. 
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TFS Releases DOS GUI Tools 

The Friendly Solutions (TFS) has released two new 
products. C*Drive++ is a C++ class library containing low-level 
windowing routines, popup and pulldown menu functions, 
form entry, and printer control. The package also includes 
classes for screen I/O, mouse and keyboard support, string 
handling, color control, a directory class and more. The library 
is compatible with Borland and Microsoft C++ compilers. 

Fastview is a new hypertext help system and help text 
compiler from TFS. With Fastview, developers can create TSR 


The Sigma NetBIOS Engine 

Sigma Software Research has released a new develop¬ 
ment kit called the Sigma NetBIOS Engine to complement 
the Windows SDK and WINDOWS.TXT (a DOS library that 
makes it easy to port Windows programs to DOS). 

The Sigma NetBIOS Engine is a small (18Kb) DLL The DLL 
provides a generic interface to all NetBIOS services supported 
under Windows. Multiple applications share NetBIOS services 
simultaneously. The DLL fully supports NetBIOS wait, no-wait, 
and post-driven requests. The package provides complete 
NetBIOS error message strings in the form of resource 
strings, to simplify error handling. By supporting WIN¬ 
DOWS.TXT, the package allows developers to develop 
NetBIOS applications for Windows and DOS from a single C 
source. 

The engine supplies a variety of functions to allocate, 
free, and manipulate NetBIOS Network Control Blocks (NCBs). 

FlashTek Releases New 32-Bit Extenders 

FlashTek, Inc., has released two new 32-bit DOS ex¬ 
tenders. X-32 is the successor to the DOSX 32-bit extender 
shipped with the Zortech C/C++ compiler. X-32 includes a 
debugger interface that allows source-level debugging with 
the existing Zortech debugger. The new version also now in¬ 
cludes spawnO, execO, and systemO functions. FlashTek is sell¬ 
ing a package to current Zortech users that allows them to 
use the existing Zortech debugger (version 3.0) with the X-32 
DOS extender. The company plans to support other com¬ 
pilers later this year. 


help text for any application. The help engine works with 
C*Drive++ or as a standalone system. 

CDRIVE++ includes source code and costs $140. 
FASTVIEW comes with source code and costs $199. For more 
information, contact The Friendly Solutions Company, 6309 
Chimney Wood Court, Alexandria, VA 22306, (703) 765- 
2063. 


Applications can create NCBs with attached data buffers that 
buffer network send and/or receive data. The engine auto¬ 
matically allocates and frees attached data buffers when 
NCBs are created and destroyed. Applications may also op¬ 
tionally specify user-allocated data buffers. 

To receive data, applications create a session and then al¬ 
locate a receive NCB with an attached receive buffer, call a 
receive strobe function, and process the NetBIOS event mes¬ 
sage when the library posts it to the window procedure. The 
engine automatically handles all post-processing functions 
supported by NetBIOS. 

The Sigma NetBios Engine is royalty-free, costs $155, and 
includes full MSC v6.x and MASM source. For more informa¬ 
tion, contact Sigma Software Research, 702 Windridge 
Drive, Atlanta, CA 303 50, (404) 992-0536; FAX (404) 992- 
0536. 


X-32 allocates extended memory from XMS, VCPI, DPMI, 
INT 15, and VDISK. This memory allocation is transparent to 
the calling application. X-32VM is the same DOS extender as 
X-32, except that it offers up to 3.5 gigabytes of virtual 
memory. The FlashTek package for the Zortech compiler in¬ 
cludes X-32VM. 

The FlashTek package for the Zortech compiler costs $69 
plus shipping and handling, and is royalty-free. For more in¬ 
formation, contact FlashTek, Inc., 804 Airport Way, Suite D, 
Sandpoint, ID 83864, (800) 379-7310 or (208) 263-7311; 
FAX (208) 263-8772; x-32vm@proto.com. 


Dragonfire Offers COBOL Toolkit 

Dragonfire Software Systems has released the PC/COBOL 
Toolkit, a set of library routines for programmers who use 
compilers based on the Micro Focus COBOL/2 Compiler. The 
library includes routines to verify diskette and printer status, 
perform screen I/O, retrieve directory listings, shell out to 
DOS, and obtain the amount of free disk space and available 
memory. The package also includes a number of copybook 

New DLL Provides Forms Processing 

WindFORM DLL is a new Windows library from Graphics 
Development International that lets programmers add forms 
processing capabilities to their Windows 3.1 applications. 
WindFORM is a Windows forms design, filling, and publishing 
program for IBMs and compatibles. With WindFORM, users 
can scan in forms and data, import graphics files, and read 
forms already created by desktop publishing programs such 
as Ventura, PageMaker, Express Publisher. 

Developers can use WindFORM DLL to read any form and 
indicate on the form the location and characteristics of the 
fields, and merge their application data with the electronic 


files that expedite the use of PC/COBOL Toolkit routines, as 
well as the Accept/Display facility and DOS interrupt calls. 

The PC/COBOL Toolkit costs $50, or $100 with source 
code. For more information, contact Dragonfile Software 
Systems, 14407 Cypress Falls, Cypress, TX 77429, (713) 
870-7966. 


form in the background. The program ships with a ScanJet 
driver, reads HP laserjet PCL Files and includes a library of 150 
standard business forms. A Small Merge Module makes it 
possible to merge data from any application. The program 
also includes the Overlay manager, a TSR users can use to 
overlay fonts or forms on top of any application data. 

WindFORM DLL costs $179.95. For more information, con- 
tart Graphics Development International, Inc., 20A Pimen¬ 
tel Ct, Suite B, Novato, CA 94949, (415) 382-6600; FAX 
(415)382-0742. 
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Ocelot2 - The SQL! 

Ocelot Computer Services, Inc, has released version 2.13 
of their package for developing SQL-based applications. The 
new version allows the system to be customized to read a 
variety of file formats, including dBASE .dbf files, by recompil¬ 
ing a module supplied in commented C source code. 

Programmers who have Ocelot's Professional Version 
receive, in addition to their royalty-free distribution license, 
support for 32-bit programming, both under DOS (requires 
Zortech’s DOSX extender) and under Windows (with WIN- 
MEM32.DLL). Using a 32-bit address space allows bigger 
catalogs and boosts performance for importing, sorting, or in¬ 


C Library Provides Data Structure Support 

Windbase Software Inc. is shipping version 1.2 of its Com¬ 
plex Data Structures Library (CDSL). Programmers can use the 
CDSL to set up and manage complex data structures, such as 
stacks, queues, dequeues, hash tables, binary trees, doubly- 
linked lists, circular linked lists, multidimensional dynamic ar¬ 
rays, and balanced and threaded binary trees. 

The CDSL multidimensional arrays can be used with any 
data lype, such as chars, integers, longs, or structures. The 
CDSL stack, queue, and dequeue structures all build on the 
CDSL linked list routines and allow you to access stacks, 
queues, and dequeues as linked lists. The balanced and 
threaded binary tree structures provide routines for adding, 
deleting, searching, and stepping. When using sorted linked 
lists, binary trees, balanced and threaded binary trees, or 


Multiport Developer's Kit for Windows 

Arnet Corporation has released a software developer’s 
kit for Windows applications needing more than two COM 
ports. The kit includes an Arnet DOS driver, Arnet Windows 
communication server application, Arnet Windows COM inter¬ 
face library, technical documentation, and sample applica¬ 
tion source. The device driver supports multiple COM ports 
per window and multiple windows with multiple COM ports, 


Smalltalk/V Update Adds MDI support 

Digitalk has updated their Smalltalk/V for Windows. The 
new version includes MDI support, a ToolPane (a window 
toolbar), a StatusPane for displaying status information, an 
ObjectFiler for sharing objects with other applications and 
developers, Help manager support, support for non-U.S. char¬ 
acter sets, and performance improvements. 

The new release also takes advantage of new features in 
Windows 3.1, while retaining compatibility with Windows 


XVT Updates GUI Packages 

XVT Software Inc. has released Release 3.0 of its XVT Por¬ 
tability Toolkit and Version 1.1 of its XVT-Design graphical, in¬ 
teractive design tool. These tools allow programmers to 
create applications that can run without source code chan¬ 
ges on six different GUIs and over 26 different platforms. 

The Release 3.0 Portability Toolkit includes new event 
types and better event dispatching. This version also allows 
both dynamic and resource-based window definition and 
creation, hierarchical menu support, and easier inter¬ 
nationalization. 

XVT-Design 1.1 allows developers to design and manipu¬ 
late all controls and attributes available in the Portability 
Toolkit, and automatically generates ANSI C code for the 


dexing large numbers of rows. The professional edition also 
has new utilities for reorganizing or checking database files. 

You can now interface Ocelot2 - The SQL! with MSC v7.0, 
as well as with QuickBASIC and BASIC PDS, Spectra Publishing 
PowerBASIC, Zortech C, and Borland Turbo C and Turbo Pas¬ 
cal. 

Ocelot2 - The SQLI prices start at $195 for a single-user 
personal edition for DOS or Windows. For more information, 
contact Ocelot Computer Services Inc., Suite 1104 Royal 
Trust Tower, Edmonton Centre, Edmonton, AB, Canada, 
T5J 2Z2, (403) 421-418/; FAX (403) 421-4187. 


hash tables (if sorted), you can supply your own comparison 
functions to define the sort or search. 

Instead of storing data in an array, the CDSL hash table al¬ 
lows you to choose either a linked list or a balanced tree for 
the storage structure. The CDSL allows you to specify the 
hashing function and also allows you to use linked list or 
balanced tree routines on the hash table. 

The DOS version of CDSL is available for Microsoft C, Bor¬ 
land C and Turbo for $139; the UNIX version costs $189.99. 
Portable C source code costs $549.99. For more information, 
contact Windbase Software Inc., P.O. Box 10115, Glendale, 
AZ 85318-0115, (602) 561-8788 or (602) 561-0667; FAX 
(602) 561-8106. 


and handles a maximum of 64 ports. Also, Arnet multiport 
boards will now include an Arnet DOS driver and an Arnet 
Windows communication server application. 

The Developer's Kit costs $295. For more information, 
contact Arnet Corporation, 618 Grassmere Park Drive, #6, 
Nashville, TN 37211, (615) 834-8000; FAX (615) 834-5 399. 


3.0. Smalltalk/V source code is compatible with Digitalk’s 
Smalltalk/V for OS/2, allowing programmers to develop on 
either platform and produce applications for both. 

Smalltalk/V for Windows, version 2.0, costs $499.95. An 
upgrade for registered users of earlier versions of Smalltalk/V 
for Windows costs $ 195. For more information, contact 
Digitalk, Inc., 9841 Airport Boulevard, Los Angeles, CA 
90045, (310) 645-1082; FAX (310) 645-1306. 


application's user interface, C header files, a makefile, and a 
Universal Resource Language file compatible with the Por¬ 
tability Toolkit 

The new products are available for Windows, Motif, 
Macintosh, Presentation Manager, and character mode. The 
Portability Toolkit costs between $1,450 and $4,400 and XVT- 
Design costs from $1,200 to $2,900, depending on the plat¬ 
form supported. Source code is available and the packages 
are royalty-free. For more information, contact XVT 
Software Inc., 4900 Pearl East Circle, Box 18750, Boulder, 
CO 80308, (303) 443-4223; FAX (303) 443-0969. 


Page 74 — Windows/DOS Developer’s Journal 


October 1992 









Reader-Contributed Tricks and Hacks 


75 


Tech Tips 


Edited by Leor Zolman 

Last issue, we featured a Tip by Philip Erdelsky about how 
to erase your floppy diskettes securely. Now that you've safe¬ 
ly wiped out all sensitive information from those old disks, 
you don’t have to worry about anyone using this next tip by 
Mr. Erdelsky to steal that data off your old discarded floppies... 

Unerase Everything! 


Philip J. Erdelsky 
4092 Ohio Street 
San Diego, CA 92104 


The idea for this Tech Tip came from a recent controversy 
involving a well-known online information service. It seems 
that this service's software creates a “staging file” on the 
user’s system to store screen images and other redundant 
data so they won’t have to keep transmitting the same things 
repeatedly. That’s a good idea - it improves their response 
time. However, some users chanced to look into the staging 
file and found material from their own deleted files in it! You 
can imagine how they felt. However, as a service repre¬ 
sentative explained it, the software simply created the staging 
file, extended it to the required size, and DOS filled it with 
what he called "debris." That’s when it occurred to me to use 
this technique as a quick and dirty recovery procedure. 

Suppose there’s something in your own erased files that 
you want to see. You can’t even remember the file specifica¬ 
tions, but you know - or hope - that the information is still 
there, and you know you can recognize it when you see it. 

The technique is simple. Just create a new DOS file on the 
same disk, use lseek() to extend it so it takes up the entire 
unused data area, less one sector (512 bytes). Then write one 
sector at the end of the file, and close the file. (You have to 
write something at the end to get DOS to extend the file.) 

Voila! The file now contains everything in the unused data 
area, except the one sector you had to sacrifice. You can use 
a text editor or a utility like browse or list to examine the 
file and search for the information you’re trying to recover. Of 
course, your disk will be 100% full at that time, so you might 
have to copy the file to another disk with more room before 
you do any editing. (The DOS backup utility will transfer the 
file to one or more diskettes without compressing or other¬ 
wise corrupting the data, although it will cut the data up into 
pieces.) 

Compile the source code file snoopdsk.c (Listing 1) with 
Turbo C 2.0 or a compatible later version. The Tiny memory 
model will do. Then type 

snoopdsk <drive letter> 

If you omit the drive letter, the current drive is used. 

The program creates a file named SNOOPDSK.$$$. If that 
name isn't suitable, just change it in the source file. □ 



Listing 1 


/* 

* snoopdsk.c: 

* Turn erased data area into a file 

* Written by Philip J. Erdelsky 
*/ 

fdefine SECT0R_SIZE 512 

linclude <stdio.h> 
linclude <dos.h> 

#include <io.h> 
linclude <fcntl.h> 

static void error_exit(char *s) 

( 

fputs(s, stderr); exit(l); 

} 

void main(unsigned argc, char **argv) 

{ 

static char FILESPECf] = "X:\\SN00PDSK.$$$"; 

char *filespec; 

unsigned long free_bytes; 

int drive, handle: 

static char buffer[SECT0R_SIZE]; 

struct dfree d; 

if (argc < 2) 

{ 

drive = 0; 

filespec = FILESPEC+2; 

) 

else 

{ 

FILESPEC[0] = argv[l] [0] & OxDF; 
drive = FILESPECfO] - ('A'-l); 
filespec = FILESPEC; 

} 

handle » _creat(filespec, 0); 
if (handle < 0) 

error_exit(“File creation error\n“); 
getdfree(drive, &d); 
if (d.df_sclus == OxFFFF) 

error_exit("Disk error\n“); 
free_bytes = (unsigned long)(d.df_bsec * d.df_sclus) 

* d.df_avail; 

if (free_bytes > SECTOR SIZE) 

{ 

printf("%ld free bytes to file %s\n“, 
free_bytes - SECT0R_SIZE. filespec): 
if (lseekfhandle, free_bytes - SECT0R_SIZE, 

SEEK_SET) == -1L) 

error_exit("File seek error\n"); 
_write(handle, buffer, SECT0R_SIZE); 
if (_close(handle)) 

error exitC'File write error\n“); 

} 

puts("Done"); 
exit(O); 

) 

/* End of File */ 
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Readers' Forum 


To the editor: 

I just finished reading the editorial of August 1992 concern¬ 
ing the idea of code reuse as a benefit of using C++. When 
finished, I had the distinct feeling that you were "throwing the 
baby out with the bath water." I feel your argument falls 
short on two important points which I would like to discuss: 

First, the idea that code should survive transition across 
such radically different applications is in my opinion a rather 
unrealistic expectation. To anticipate that a piece (or pieces) of 
code should be usable in environments ranging from multi¬ 
threaded applications to embedded systems seems to me a 
bit too much to ask of any language or development environ¬ 
ment. 

Having said that, my second point would be that you are 
missing the real realm of possibility which C++ presents for 
code reuse, and that is intra-application. There are many in¬ 
stances when developing an application (or set of highly re¬ 
lated applications) when we are confronted with the need for 
several pieces of code or data all of which differ only slightly. 
It is in these cases that, through the inheritance and polymor¬ 
phic mechanisms of C++, a great deal of code reuse can be 
realized. I could present many such examples, but for a truly 
enlightening discussion of this concept I would refer you (and 
your readers) to Robert Martin's article entitled "Abstract Clas¬ 
ses and Pure Virtual Functions" appearing in the July/August 
1992 issue of C++ Report. Through the explanation of abstract 


classes and virtual functions, Mr. Martin presents an excellent 
picture of the possibility of code reuse in a C++ application. 

In summary, I would like to say that while C++ is not the 
panacea of solutions for code reuse which the fanatics claim, 
it is also not the “just another C" which the pessimists con¬ 
tinue to maintain. As with any language, C++ has its strengths 
and weaknesses, of which further examination will show its 
ability to encourage code reuse to be a definite strength. 

Ron Cox 

Paragon Consulting Group 
Phoenix, AZ 

Thanks for the thoughtful comments. I definitely agree 
that C++ offers more opportunities for reuse than C, which 
is one reason Burk Labs uses C++ exclusively. Neverthe¬ 
less, code reuse is a complex issue, and the fact that no 
one has yet constructed a single “List" class that a sig¬ 
nificant percentage of C++ programmers reuse is porten¬ 
tous of the depth of the problem of achieving code reuse, not 
necessarily of the inability of the language to support it. -rib 


Code Correction 
Dear Ron, 

In implementing my PUSH/POP routine (“PUSHA/POPA 
Emulation," August 1992, pp. 43-46) in another program today, 
I discovered to my chagrin that I left out several required CS: 



Developer's 

Marketplace" 



Basic is better than C when you 
use the ProBas library! Over 900 
routines, most in assembly, let you 
write fast, tight code without 
"C-headaches"! Easy to use, 30 
day money-back guarantee. For 
your FREE 20 page booklet call: 

800-447-9120 ext. 158 

TeraTech 

W158,3 Choke Cherry Rd., 
60, Rockville MD 20850 
330-6764 Fax: 963-0436 
963-7478 9600-N-8-1 
"A Supercharger for Basic" - BYTE 
New Visual Basic tools available! 

□ Request 101 on Reader Service Card □ 
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Loose Data Binder 
(LDB vl.7) 



Now you don't need an ODBMS to implement 
persistent data objects thanks to the Loose Data 
Binder (LDB 1.7 C++). LDB provides for strong type 
checking with or without C++ templates and includes 
an unconventional persistent container class having 
a hybrid stack, queue, deque, list, array interface 
and built-in sort, search, and iterator functions in one 
flat class. Use LDB to implement algorithms that 
conventional “textbook" container libraries can’t 
touch. An LDB network of containers/elements can 
be streamed using only one insertion/extraction 
operation. Use LDB as a kernel (typically less than 
10k) for rolling your own framework/CASE tool, etc., 
without the overhead or cost of an underlying 
ODBMS. Includes 100+ page manual, royalty free 
OEM friendly license agreement, NG help, and 
source on both 3.5" and 5.25" DOS diskettes. See 
CUJ’s May 92 “New Products." Scott Guthery of 
Austin Code Works calls LDB “a sweet piece." Only 
$60. To order call (703) 759-3838. 

PSW/ Power Software 
P.O. Box 10072, McLean, VA 22102-8072. 


□ Request 173 on Reader Service Card □ 
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Windows 
Developer Jobs 


Specialists in jobs for software 
engineers in leading edge technology. 
Windows, PM, GUI, Languages, AI, 
Mac, CASE, Video, Realtime. 
Nationwide contacts with both large 
and small companies including equity 
startups. Many of our clients develop 
and publish commercial software 
products. Managed by graduate 
engineers. Never a fee to an 
applicant. 

1-800-231-5920 



Scientific Placement, Inc. 

SPI-8, Box 19949, Houston, TX 77224 (713) 496-6100 
SPI-8, Box 71, San Ramon, CA 94583 (510) 733-6168 
SPI-8, Box 4270, Johnson City, TN 37602 (615) 926-6188 
Fax: 713-496-6802 please use Fine Setting on Fax 
Email: Ascii preferred: Internet LSH@Scientific.com; 
^CompuServe: 71250,3001; Genie: D.SMALL6 


□ Request 335 on Reader Service Card □ 
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TUB ™ is FASTEST! 
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RCS™ 4.2 PVCS'" TUB'" 3.0 TUB " 5.0 


Times are to update a 45K library on a PC/XT. PVCS and TUB 3.0 are 
from Sept 87 PC Tech Journal. MKS RCS 4.2 and TUB 5.0 are newer. 


TUB™ is BEST! 

“Do not be fooled by the fact that this is the 
least expensive of the five packages reviewed 
here - TUB has features and power to spare" 
John Rex, Computer Language 
“TUB is a great system" J. Vallino, PC Tech J 

• Full-Featured Version Control for Software 
Professionals. Check-in/out locking. Branching. 
Keywords. Wildcard and list-of-file support. Can 
merge parallel changes and undo intermediate 
revisions. Network and WORM support. Main¬ 
frame compatible deltas for Pansophic, ADR, IBM, 
etc.. Integrates with Opus “ MAKE & Slick" MAKE. 

MS-DOS $139, OS/2 $195 + shipping Visa/MC 
5 station LAN license $419 (OS/2 $595), call for other sizes 

BURTON SYSTEMS SOFTWARE 

PO Box 41 56, Cary, NC 27519 (919)233-8128 
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Notice to Our Subscribers 

Occasionally, Windows/DOS Developer's 
Journal makes its mailing list available to 
vendors of products we think our readers 
will find interesting. Current subscribers 
receive free information in the mail from 
these vendors. If you prefer that your 
name not be used in these mailings, 
please let us know. Just copy or clip this 
form and send it with your name and ad¬ 
dress tO: 

Windows/DOS 

□ DEVELOPER S JOURNAL 

1601 W. 23rd. SL, Ste. 200 
Lawrence, KS 66046-2743 


Fastgraph 

programmer's graphics library 


Unlock the secrets of high- 
performance DOS graphics 
programming with the graphics 
library commercial games 
programmers have used for 
years. 

C • C++ • Pascal • BASIC • FORTRAN 

Only $169 

Call today for a free demo disk or download an 
evaluation kit from our BBS. No royalties. 
Visa, MC, COD, and purchase orders welcome. 

Ted Gruber Software 
PO Box 13408 Las Vegas, NV 89112 
Orders/Info (702) 735-1980 
FAX (702) 735-4603 • BBS (702) 796-7134 


□ Request 133 on Reader Service Card □ 



Visual Basic, 
BASIC, and PDS 
programmers! 

j*6gTTira! Purpose Toolboxes 
Design 

..r^^rtimunications 
jUtS&R* Printing 


Stfenfific Applications 
,#l5fs and more! 



Crescent Software offers many tools for 
QuickBASIC, PDS, and Visual Basic. All 
products include complete source code, 
free technical support, and royalties ore 
never required! rom^&nKDnoMcuas 
CALL TOLL FREE 
n M 1 800 35 BASIC 



CRESCENT SOFTWARE, INC. 

11 BAILEY AVENUE 
RIDGEFIELD, CT 06877-4505 
203438 5300 FAX 203 431 4626 



Great Graphics 
for Scientists and 
Engineers! 
FORTRAN, C, 
QuickBASIC, and 
Pascal. 


INGRAF 


supports video, printers, and plotters 


Over 100 routines 
give you complete 
control of axes, 
scaling, windows, 
and more 

Sutrasoft 

10506 Parmlan Dr. 
Sugar Land, TX 77478 

Info: (713) 461-2088 

FAX: (713) 240-6883 


Source code. 
No royalties. 

$350 
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Write bar Barcode Products 


Wilsoft carries a complete line of bar 
code software and hardware for your 
every need. All major bar code types 
supported. Call the most experienced 
company in the bar code field today. 
DOS and Xenix/Unix support. Por¬ 
table readers too! 

VISA/MC/AMEX/DISCOVER 

PO Box 6186 

Ft. Lauderdale, FL 33310-6186 
(305) 779-2720 
(305) 763-3096 Fax 
(800) 779-2720 Sales 


□ Request 142 on Reader Service Card □ 


Simtel MSDOS CDROM $24.95 

550 meg, 8300 programs. Programming tools, 
dos utilities, tech docs, comm, bbs, publishing, 
ham-radio, education, much more. Made June 92. 

CICA MS Windows CD $24.95 

Hundreds of MS Windows programs. Utilities, 
games, source code, programming tools. July 92. 


Source Code CDROM $39.95 

Desktop Lib CDROM $39.95 

GIFs Galore CDROM $24.95 

OS/2 Archive CDROM $24.95 

CDROM Caddies $4.95 


Walnut Creek CDROM 

1547 Palos Verdes Mall 
Suite 260 

Walnut Creek, CA 94596 
+1 800 786-9907 
+ 1 510 947-5996 
+1 510 947-1644 FAX 
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overrides in the published listing. 1 had them in my test code 
but somehow failed to include them in the listings in the article. 

The code in the listing will run as is, but if the user chan¬ 
ges DS and then invokes PUSH_POP, the discard POP of the 
address to the NULL_WORD variable is going to pop the value 
relative to DS and not CS. This can cause intermittent failure of 
the program depending on where DS is pointed at the time. 
The same applies to Moving an address into temporary 
storage. 

All POPs or MOVs to the variables NULL_WORD, NEAR_AD- 
DRESS, or FAR_ADDRESS should have CS: overrides. 

The three instances in Listing 1 (p. 44) are: 


The four instances in Listing 2 (pp. 45 - 46) are: 

MOV FAR_ADDRESS,AX 

CALL FAR_ADDRESS 

POP NULL_W0RD 

POP NULL_W0RD 

They should read: 

MOV CS:FAR_ADDRESS,AX 

CALL CS:FAR_ADDRESS 

POP CS:NULL_WORD 

POP CS:NULL WORD 


MOV NEAR_ADDRESS,AX 

CALL NEAR_ADDRESS 

POP NULL_W0RD 

They should read: 

MOV CS:NEAR_ADDRESS,AX 

CALL CS:NEAR_ADDRESS 

POP CS:NULL WORD 
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Tech Graphics 
A ny Language 

SEGS-RT is the runtime version 
of our Scientific & Engineering 
Graphics Systems that can be 
called from any language. 

♦ Curve fitting & smoothing. 

♦ Log, time/date & linear axes. 

♦ Most video, hardcopy devices. 

♦ Up to 10 curves & 99,999 pts. 
30 Day Money-Back Guarantee 


Advanced Micro Solutions. Inc 
3817 Windover Dr Edmond, OK 73013 
405-340-0697 Now Only $195 
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Marketplace 



JPEG 

Image Compression 
for Windows 

★ Compress/Decompress images in 
10 seconds or less. 

★ Full Source Code & DLL’s Available 

★ Convert & View Multiple Images 

■k Royalty Free Developers Kit Available 
■k PRICES START AT $99.00! 

Regular and Extended Dos also available 
•a PHONE: 1-800-966-4487 
305-962-9961 
FAX: 305-962-6546 

Information Technologies Research,Inc 
3520 W Hallandale Beach Blvd 
Pembroke Park, FL 33023 
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Windows 3.1 
Text Printing Utility 

Causality for Windows 

“Prints source code in a flash” 

Fast! Easy! Flexible! 

Install, configure, and forget about 
it. It’s that easy! Drag files from File 
Manager and Drop on Causality for 
Windows. Causality formats and 
prints them to your specifications. 
Customize tab expansion, orientation, 
font face, font size, and margins for 
each file type you use. Causality 
automatically remembers your 
settings. 

Just $79. Call or write for a demo. 

Non-Causal Systems, Inc. 1-800-221-9423 
4691 N. University Dr., Suite 384 
Coral Springs, FL 33067 

□ Request 150 on Reader Service Card □ 


COM1: - COM4: 
WITH WINDOWS! 

• 1, 2, OR 4 PORT RS-232 BOARDS 
. RS-232 AND RS-422 VERSIONS 

• W1NOOWS UTILITY SOFTWARE 
PROVIDED 

• XT AND AT INTERRUPT JUMPERS 

• OTHB1 PRODUCTS INCLUDING 
LAPTOP AOD-ONS 
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INTERNATIONAL 
SOFTWARE 
ASSIGNMENTS 

YOUR PASSPORT TO AN 
INTERNATIONAL CAREER 

The International Computer Professional Association 
provides you with the world-wide contacts you need to find an 
exciting software assignment overseas. 

Every two weeks you'll receive a detailed listing ol 
current software assignments taxed directly to the ICPA by 
recruiters in London, Paris, and many other cities. Youll also 
receive valuable advice from software professionals with first- 
hand international experience. 

•Learn about exdfng contract and permanent poeiScns overseas 
• Make up to $70,000 tax-free, even when working in Euope 
•Set-up an international ccxtsuitancy and work throughout lha world 

As a member of ICPA you become part ol a dynamic 
international network of software professionals. People with 
years ot experience in the international market who will show 
you how to find an assignment overseas. 

To find out more about how to join the ICPA 

Call (415) 695 7618 



Given the subtle nature of the routine itself, it’ll be hard for 
someone to isolate this problem if it crops up in an applica¬ 
tion. 

Regards, 

Stephen Nebel 
P.O. BOX 72550 
Fairbanks, AK 99707 

Thanks for the fix! -rib 





















B3T TCP/IP 

programmers! 

GENISYS Comm Pack++ 

GCP++ is 100% C++ DLL, providing 
a middleware API for encapsulated 
TCP/UDP/Telnet access, buffer, file, 
and packetized voice. 

>- Eliminate socket library learning 
curve 

>- Speed development & debugging 
>- WinSock standard provides portability 
► No Royalties! 

We do custom Windows & 
voice/data networking applications! 

GENISYS Comm, Inc. 

314 South Jay Street, Rome, NY 13440 

_ (315) 339-5502 _ 

□ Request 112 on Reader Service Card □ 


f Windows Developers:^ 

Put an End to Memory Problems! 


- (formerly OptiMem) 

SmartHeap™ Optimal memory manage- 
for Windows men! DLL for Windows 3.x. 


□ Fixes selector consumption, overhead, granu¬ 
larity, fragmentation. Supports heaps > 64K. 

□ Dramatically improves performance. 

□ ANSI C malloc, C++ new, dozens more APIs. 

□ Detects memory bugs including double-freeing, 
memory overwrites, wild pointers, and more! 

□ Programmatic heap walking and error handling. 

□ Ideal for dynamic data structures, e.g. lists. 


CSr 1 Only $395. (800)441-7822 

No royalties. Free, unlimited technical support. 
Unconditional 60-Day Money-Back Guarantee! 

Call to order or to request technical white paper description! 


MicroQuill Software Publishing, Inc. 

,4900 25th Ave., NE, #206 • Seattle, WA 98105, 
Fax (206) 525-8309 • (206) 525-8218 
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Beat the Clock. 


> Performance Analysis 

■ Execution Timing 

■ Periodic Interrupts 

■ Precision Delays 
' Manual Interrupts 



£ 77 ( 77 ' 


S.'295 


Independent hardware provides five 16-bit 
250-nanosecond timers. Includes add-in card, 
breakout switch, reference guide, application 
and l/F library with FULL SOURCE CODE. 

(/£77(77 ™ $w9 

Virtual timers library for STATE Support 
included for most 9513 counter/timer boards. 
FULL SOURCE CODE INCLUDED. 

£77/P/™ #29 

Debugger breakout switch and interface card. 

CALL (206) 644-3094 TO ORDER 

ALPHA LOGIC 

TECHNOLOGIES INC. 

2121 IS2ND AVE N.'e.. REDMOND WA 98052 i 
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$79 DATA ACQUISITION FOR PCs 

■ 24 LINES OF PROGRAMMABLE DIGITAL INPUT/OUTPUT 

■ 3 CHANNEL 8 BIT A/D CONVERTER 

■ 12 BIT COUNTER 

■ PLUGS INTO PC BUS AND INCLUDES MANUAL AND 
FLOPPY 

$149 TRUE RMS DMM W/RS232 

■ MEASURES AC/DC VOLTS, CURRENT, OHMS, 
FREQUENCY 

■ OPTO-ISOLATED SERIAL PORT WITH CABLE FOR PC 

■ 20 AMP CURRENT RANGE, 30-40KHZ FREQUENCY 

■ INCLUDES CABLE AND DATA-LOGGING SOFTWARE 

$239 A/D CONVERTER W/RS232 

■ 18 BIT 5.5 DIGIT RESOLUTION (1 IN 200,000 COUNTS) 

■ ADDRESSABLE, CONNECT UP TO 32 ON 1 RS232 PORT 

■ VIRTUAL INSTRUMENT SOFTWARE & CABLE INCLUDED 


PRAIRIE DIGITAL INC. 

846 17THSTR INDUST PARK 
PRARIE DU SAC, Wl. 53578 


MAIL, FAX, OR PHONE 
VISA, MC, CHECK, M0, 
OR P0 ACCEPTED 


TEL 608-643-8509 INCLUDE $8 FOR S&H 

FAX 608-643-6754 


□ Request 110 on Reader Service Card □ 


BAR CODE 
SOURCE CODE 

$45.00 

Source code for printing UPC codes, 
postal bar codes, and most other 
popular formats. Comprehensive 
collection of programs and routines 
in C, C++, Paradox, Quick Basic, 
GW Basic, Visual Basic, & Dbase. 
No runtime royalties. 

Eastern Digital Resources 
PO Box 1451 - Clearwater, SC 29822-1451 
Tel. (803) 593-0870 Fax. (803) 593-4522 
VISA - MC - COD - PO'S WELCOME 


□ Request 119 on Reader Service Card □ 


32-bit Protected Mode 
386 C Graphics Library 

Intel 386/486 C Code Builder 
MetaWare, MicroWay, SVS, 
Watcom & Zortech with 
Phar Lap 3861 ASM 

Mixed Raster/Vector, 
Scalable, Rotatable Font, 
VGA, SVGA, 8514/A, VESA, 
Hercules Graphics Station 
through 1024x768x256 (8-bit), 
640x480x32k (16-bit), 
512x480x16.7m (32-bit), 
WYSIWYG HP-GL/PostScript 
$200 NO ROYALTIES 
FULL SOURCE CODE 
Gary R. Olhoeft 
P.O. Box 10870 Edgemont 
Golden, CO 80401-0620 
303-877-3697 CIS 76665,2021 

□ Request 294 on Reader Service Card □ 


If you're reading this 
ad — you're one of 
the thousands of 
programmers who 
read 

Windows/DOS 
Developer's Journal 
monthly. 

Call (913) 841-1631 
today to reserve 
space for your ad. 


October 1992 


C and C++ DOCUMENTATION 


! AUTOMATED DOCUMENTATION I 

• C-CALL ($69) Graphic-tree of caller/called 
functions, cross-ref, file/function index. 

• C-CMT ($69) Creates/inserts/updates 
comment-blocks for each function, listing 
the functions and identifiers used by it. 

• C-METRIC ($59) Counts path complexity, 
counts comments, code, 'C' statements. 

• C-LIST ($69) Lists and action-diagrams, 
or reformats into standard formats. 

• C-REF ($59) Creates cross-reference of 
local/global/define/parameter identifiers. 

• SPECIAL : C-DOC ($199) All 5 programs 
integrated as DOS program (<15,000 lines) 

• NEW! C-DOC Professional ($299) 

DOS, OS/2, Windows. 3-ring binder/case. 
Processes 150,000 lines, deferred reports. 

• 30-DAY Money-back guarantee CALL NOW 


SOFTWARE BLACKSMITHS INC. 

6064 St Ives Way, Mississauga 

ONT, Canada Voice/Fax (4161-858-4466 

L5N-4M1 Demos/BBS (4161-855-1916 


see AD INDEX for our larger ad 
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VB Code without 

THE COMPROMISE 


If you're tired of 

WCompress" rewards 

having to choose 

good programming practice: 

between VB code 

Write code the way you should 

that is readable 

with plenty of white space, 

and EXEs that are 

comments, and descriptive names. 

the smallest and 

Manage code the way you want 

fastest they can be, 

with standard global files and 

then you need... 

libraries of standard routines. 

r VB. 

Forget about that “code save/ 
code load’' nonsense. 

Create VB EXE files that are 

Compress 

smaller and load faster without 
spending hours "optimizing" 

It lets you 

your code. 

have it 

Just ^49.95 plus $5. s&h. 

For orders or information call: 

both 

TAILORED PCs 

ways! 

1-800-241-8727 


□ Request 287 on Reader Service Card □ 
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FREE 

Product 

nformation 

Use this postage paid 
card to stay up-to-date 
on products 
that affect 
your productivity. 

Just fill out the card 
and drop it in the mail. 


Windows"/ DOS 

□ DEVELOPER'S JOURNAL 


1601 W. 23rd St„ Suite 200 
Lawrence, KS 66046-9950 
(913) 841-1631 FAX: (913) 841-2624 


Please help us serve you by 
answering the following: 

1) I program: 

□ for a living 

□ as a hobby 

□ as a manager 

2) I program in: 

□ MS-DOS 

□ Windows 

3) I program most frequently in: 

□ C+ + 

□ Assembly 

□ Pascal 

□ BASIC 

□ C 

□ Other_ 

□ Please send me subscription information. 


REQUEST READER SERVICE NUMBERS: 



Use with the October 1992 issue only. 


NAME 

COMPANY 

ADDRESS 

CITY/STATE/ZIP 

PHONE ~ 



Windows/DOS 

□ DEVELOPER'S JOURNAL 

□ YES! Send me 12 issues of Windows/DOS Developer’s Journal for only $29! 

□ 2 years (24 issues) for $54 □ 3 years (36 issues) for $77 

□ Bill Me □ Visa □ MasterCard 

Number_Exp._ 

Signature_ 


Name 


Company 


Address 

City 

State 


Zip 


Country/ProvincelMailcode 


3.10 


Please allow up to six weeks for delivery of first issue. Orders outside the US must be prepaid in US funds. CANADA/MEXICO 
subscriptions are: 1 year - $53; 2 years - $88; 3 years - $121. Overseas subscriptions are: 1 year - $64; 2 years - $120; 3 years - $174. 
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Information 


Windows/POS 

□ DEVELOPER'S JOURNAL 

1601 W. 23rd St., Suite 200 
Lawrence, KS 66046-9950 


Use this postage paid 
card to stay up-to-date 
on products 
that affect 
your productivity. 


Just fill out the card 
and drop it in the mail. 
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Date txpr 

Field Index Memo 


d4alias 

d4free_blocks 

d4recall 

d4alias_set 

d4go 

d4reccount 

d4append 

d4go_eof 

d4recno 

d4append_blank 

d4Jock 

d4record_widtl 

d4append_start 

d4Jock_append 

d4reindex 

d4blank 

d4iock_file 

d4seek 

d4bof 

d4lock_group 

d4seek_doublf 

d4bottom 

d4lock_index 

d4skip 

d4check 

d4lock_test 

d4tag_select 

d4close 

d4Jock_test_append 

d4top 

d4close_all 

d41ock_test_file 

d4unlock_all 

d 4 ere ate 

d 4me m o_co m p re s s 

d4unlock_appe 

d4delete 

d4num_fields 

d4unlock_file 

d4deleted 

d4gpen 

d4unlock_inde 

d4eof 

d4pack 

d4unlock_reco 

d4field_number 

d4position 

d4update_heai 

d4flush_all 

^J4nosition_set 

d4write 

d4flush record^l 

_ 

d4zap 


oggriH 


Field Functions 


Database : 


Field to View: 


O void fdassig 


CUSTOMER 


Done 


NAME 


BIRTH_DATE 

COMPAN Y 

PHONE 
SEX 


Change Database 


FISCHER, ANDY 


O void f4blankfr 
O int f4char() 

O int f4decimals[) 
O double f4double() 
O int f4int() 
o unsigned f4len( ] 
O long f4long() 


cnar*f4name(] 
® char *f4str() 

O int f4true() 

O int f4type( ] 

Return Value : 



Multi-user 

DOS, Unix, OS/2 Support 
C++ Interface Included 
Windows 3 Data Entry 
Clipper C Translator Available 


Complete DBMS for C, C++ and VB 
programmers - compatible with the data, 
index and memo files of dBASE III/IV, 
FoxPro 2 and Clipper. Try the super-fast, 
super-small FoxPro 2.0 CDX index files! 


M 


DATA BASED 

M2*yns(EM 



(Using Visual Basic? Try CodeBasic!) 



The C Library for DataBase Management 



SEQUITER I 

SOFTWARE INC. I 


TEL. 403*437*241 0 

FAX 403*436*2999 

Europe 33.20.24.20.14 


#209,9644-54 AVE., EDMONTON, AB, CANADA T6E-5V1 
□ Request 126 on Reader Service Card □ 


































































New BOUNDS-CHECKER 2.0 



Welcome to the age of 
automated memory/heap protection! 

NEW BOUNDS-CHECKER 2.0 is the 2 Q!y complete solution to MS-DOS 
memory 2 nd heap corruption problems. 

BOUND-CHECKER 2,0 is a single, easy to use utility that automatically 
detects problems in your programs heap, stack or data segment and 
finds illegal memory accesses outside of your program or in your code. 
In one step, you can quickly and easily flush out some of the most 
insidious bugs that you regularly encounter as a DOS programmer. 


• New 2.0 Features • 

• Now works with 3rd party memory managers 

• Heap, stack and data segment checking 

• Smart Mode decides the legitimacy of an access automatically 

• No need to see assembly code - call stack lets you view source 
of calling routines. 

• New Auto Log mode (BC doesn't pop up) 

• Supports C7.0 & Borland 3.1 & VROOM 

Order NOW! Only $199 


Using BOUNDS-CHECKER 2.0 is simple, there are no changes to be made 
to your source in any way, and no linking of code or macros into your 
executable. When a bug is found, BOUNDS-CHECKER pops up showing 
you precisely where the problem is. 

One of its innovative NEW features is Smart Mode. Smart Mode uses a 
built-in knowledge base to automatically determine if an out-of-bounds 
access is legitimate. This eliminates any complex decisions on your part, 
resulting in more power and flexibility than you may have thought 
possible. 

Don't take unnecessary risks with your program or your customers. 
BOUNDS-CHECK before you ship with NEW version 2.0. 


For even more debugging power, BOUNDS-CHECKER 2.0 
integrates with our award-winning Soft-ICE debugger which fea¬ 
tures powerful 386/486 based breakpoints. Equipped with this 
formidable combination, your de-bugging arsenal is prepared for 
any surprise attack of the DOS Nasties. 

Soft-ICE...$386 

BOUNDS-CHECKER 2.0 & Soft-ICE Bundle Only...$499 

BOUNDS-CHECKER AND SOFT-ICE ARE TRADEMARKS OF NU-MEGA TECHNOLOGIES. INC. 


We're making C a Safe Language! 


Call (603) 889-2386 
fax (603) 889-1135 

if 1 

N 

Ur] 

M 

tea 

n 

RISK = NULL 

30 DAY 

MONEY-BACK GUARANTEE 

P.O. Box 7780 

Nashua. NH 03060-7780 U.S.A. 

^TECHNOLOGIES INC 

24 HOUR BBS 
603-595-0386 
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